Clojurians Log v2

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

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)

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

state/app-state is a reagent atom

oh lol, there's a misplaced ]

What do you mean with a subscription of a subscription?

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

yeah, thats a problem with :target :bundle.

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.

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

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.

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

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

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.

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

@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

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 😞

derp ^:dev/after-load apparently

https://code.thheller.com/blog/shadow-cljs/2019/08/25/hot-reload-in-clojurescript.html

I could be wrong but I think this is what deftime (from Macrovich) is for

Imma check it.

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

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

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?

yes. which static list are you refering to?

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

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

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

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

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.

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

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

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] https://github.com/nrepl/weasel