This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # aleph (11)
- # announcements (1)
- # babashka (9)
- # beginners (90)
- # calva (6)
- # clj-kondo (24)
- # cljs-dev (26)
- # clojure (92)
- # clojure-europe (48)
- # clojure-nl (1)
- # clojure-spec (4)
- # clojure-sweden (2)
- # clojure-uk (41)
- # clojurescript (60)
- # code-reviews (1)
- # conjure (6)
- # core-logic (3)
- # datascript (1)
- # datomic (3)
- # deps-new (1)
- # depstar (4)
- # dirac (3)
- # emacs (8)
- # fulcro (1)
- # helix (27)
- # introduce-yourself (2)
- # jobs (1)
- # off-topic (4)
- # pathom (2)
- # polylith (8)
- # re-frame (3)
- # remote-jobs (1)
- # shadow-cljs (5)
- # spacemacs (2)
- # tools-deps (22)
- # vim (3)
- # xtdb (27)
Ok, I’ve got a problem I’m trying to wrap my head around. This is a clojurescript file, intended as a node script in the end. The purpose of these few lines is just to get a list or sequence of strings from files.
When I run
(ns app.parser (:require ;[...] [cljs-node-io.core :as io] [cljs-node-io.fs :as fs])) (def all-filenames (let [path "src/posts"] (rest (io/file-seq path)))) (def all-org-docs (map #(fs/readFile % "utf8") all-filenames))
mapon all my files, it concatenates the strings from the files rather than returning a lazy-seq. Is this a quirk of cljs’
cljs-node-io, or something else? Using
cljs-node-io.core/slurpin place of
cljs-node-io.fs/readFilegives me the same result.
app.parser=> (map #(fs/readFile % "utf8") all-filenames) ;;actual ("#+title: my blog post... ... ...) ;;expected (("#+title: my blog post...")("#+title: second blog post..."))
I wouldn't expect each file's contents to be wrapped in a list. Does the result include a number of strings that matches the number of files or one big long string? In other words what's the result of:
(count (map #(fs/readFile % "utf8") all-filenames))
If you did want each file's content wrapped, you could try:
(map #(list (fs/readFile % "utf8")) all-filenames)
Thank you @U7RJTCH6J. I guess I just didn’t realize that they were in fact surrounded by quotes.
I'm trying to use setInterval and clearInterval but for some reason the clearInterval isn't working... any tips? https://gist.github.com/Sose/c20a64b64b64b47fde7183e4932b9885
Quick poll: Are you using "https://clojurescript.org/guides/webpack" as per the website guide?
(I ask because I hit super slow compilation times after converting a large project over from the old :foreign-libs approach. Wondering if it's proven itself a best practice now.)
can't comment on how many people use it but compile times will be whatever you had before + however long webpack takes (which can be quite long, depending on how much you use)
Thanks. I think my issue was webpack trying to optimise the advanced compiled output from cljs (from memory).
its really a problem with
:target :bundle not so much webpack. the output of the CLJS build is just passed to whatever other tool you are using. that tool should run some optimzations for the "other" JS code it gets. I'm not aware of any options that let you skip re-optimizing the CLJS output but still optimize the rest.
No doubt shadow-cljs is good but I haven't stopped long enough to get familiar with it.
I'd be interested to hear if others have struggled with crazy slow build times using
:target :bundle. If so I'll petition for some warnings to be added to the webpack guide on the CLJS website.
It was madness, like 10 mins. I https://ask.clojure.org/index.php/9602/recommended-webpack-config-for-clojurescript-bundle-target?show=9602#q9602 but didn't get much help.
it’s so bad that we don’t do it for each autodeloy from master to dev env, but only for release builds… I haven’t found a solution to it yet
haven’t looked into it recently, the webpack replacements I tried a year ago didn’t really work
Thanks. Sounds like I'm not the only one then. The gist associated with that question has some commented out terserOptions which you might like to try (no promises).
@olivergeorge the dev-cycle is very acceptable to me. Obviously, no TerserPlugin there. prod-cycle takes a few minutes, not in a way that blocks me
@olivergeorge I think you probably need to dig into this more - like is this a memory issue?
far as I can know other people using webpack plus bundle on large projects who haven't reported extravagant build times
@olivergeorge also based on your report this doesn't really have anything to do w/ Webpack, but perhaps the Terser plugin
certainly haven't seen this Metro & bundle target which is a different flavor of the same thing - build times are not extravagant at all
in any case since this is the first report I've seen, not really interested in changing anything on the website at this time - need a lot more information first
Thanks for the tips/thoughts. I'll give it another go and aim for a minimal repro if it pops up again.
also Terser does allow exclusions - https://stackoverflow.com/questions/56557986/webpack-terserplugin-exclude-node-module
I'm proper confused. I've created a shadow-cljs project and added reagent, and when I run the watcher and make changes to my reagent example, it recompiles, I see a brief spinning logo at the bottom left in the browser, but the react component is not updated unless I manually reload the whole browser. This worked last week when I first experimented with shadow-cljs and reagent 😞
I have a shadow-cljs question regarding polyfills - I'm struggling to figure out if
:output-feature-set :es5 is doing anything, and if so, what polyfills it is including. Is there a good way to get this information?
polyfills depend on the code you use, I guess there is no easy way to tell which are included. the data exists but it isn't printed anywhere or so.
Okay cool. Maybe we simply don't use these 😧 . I'll keep digging. Thank you! Right now we have a static list of polyfills we include, but I'd like to drop them if we can. It just gives me a little bit of anxiety. Do these polyfills come from closure compiler?
require("core-js/es6"); require("core-js/fn/array/includes"); require("core-js/fn/string/pad-start"); require("core-js/fn/string/pad-end"); // ... etc
I'm concerned about that too 🙂. Some of this is carry over from our old figwheel build process. I can't actually see if these functions are being polyfilled in our production output though. Which means either: 1. Our shadow-cljs config needs to be corrected 2. We aren't using these at all, and so the shadow-cljs release build isn't including them.
yeah its kinda tough sometimes since
:advanced can inline some polyfills if only used once and that sort of stuff
the closure compiler will analyze the code and only end injecting what is actually used
Right. I guess part of me is a little anxious about it picking up stuff in some of our NPM dependencies. I suppose we have externs.
The compromise I've come to right now anyway is to load this script with
<script nomodule> , which dovetails nicely with our browser support situation.
hello! I'm using Weasel  instead of the browser REPL. is there any way to avoid adding the XPC iframe besides manually removing the following line from the JS output?