Fork me on GitHub

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.

(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))
When I run map on all my files, it concatenates the strings from the files rather than returning a lazy-seq. Is this a quirk of cljs’ map function, node’s fs, cljs-node-io, or something else? Using cljs-node-io.core/slurp in place of cljs-node-io.fs/readFile gives me the same result.
app.parser=> (map #(fs/readFile % "utf8") all-filenames)
("#+title: my blog post... ... ...)
(("#+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)


Imma check it.


count returned 4. I didn’t notice that they were all separate strings.


Thank you @U7RJTCH6J. I guess I just didn’t realize that they were in fact surrounded by quotes.

👍 3
Joni Hiltunen07:05:39

I'm trying to use setInterval and clearInterval but for some reason the clearInterval isn't working... any tips?

Joni Hiltunen07:05:48

state/app-state is a reagent atom

Joni Hiltunen07:05:23

oh lol, there's a misplaced ]

Oliver George11:05:57

Quick poll: Are you using "" as per the website guide?


I am. The initial bundler is slow, and then the development cycle stays fast.

Oliver George11:05:52

(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)

Oliver George11:05:43

Thanks. I think my issue was webpack trying to optimise the advanced compiled output from cljs (from memory).


yeah, thats a problem with :target :bundle.

Oliver George11:05:46

Any chance you know a webpack alternative I could switch in for this use case?


well shadow-cljs doesn't have this problem 😉


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.

Oliver George11:05:39

Thanks anway. Seems like a fight I should walk away from really.

Oliver George11:05:23

No doubt shadow-cljs is good but I haven't stopped long enough to get familiar with it.

Oliver George11:05:49

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.


how crazy slow are you seeing? shouldn't be that extreme?


yeah the webpack minimize takes a really long time, in our build it’s 15 minutes


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

Oliver George04:05:41

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).


I’ll check it out, thanks


our (unminified by webpack) advanced compilation output is 5mb 😅


the webpack minification shrinks it to 3.6mb


hmm yeah no clue about that. seems a little excessive


@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

👍 4

@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

Oliver George22:05:23

Thanks for the tips/thoughts. I'll give it another go and aim for a minimal repro if it pops up again.

Pepijn de Vos13:05:53

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 😞

Pepijn de Vos13:05:03

derp ^:dev/after-load apparently

Nate Hunzaker17:05:28

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.

Nate Hunzaker17:05:15

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?


yes. which static list are you refering to?

Nate Hunzaker17:05:30

We just have a javascript module that requires a bunch of ES6 polyfills, roughly:


// ... etc


why? that will at the very least lead to duplicated polyfills for most cases

Nate Hunzaker17:05:57

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


but it won't account for core-js already providing some

Nate Hunzaker17:05:36

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.

Nate Hunzaker17:05:21

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.

Nate Hunzaker17:05:33

Anyway, thanks! This was super helpful


Is there a good way to detect the browser environment in Clojurescript?


google closure has some agent detection stuff

👍 3

hello! I'm using Weasel [1] 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? document.write('<script>goog.require("clojure.browser.repl.preload");</script>'); [1]