Clojurians Log v2
shadow-cljs
While working on code splitting, I'm looking at a build report and it shows 100kB of cljs.pprint included in my release build, required by cljs.test. I don't need tests in my release build, nor do I need cljs.pprint — I thought those would automatically get excluded?
You are incredible! However, I'm not sure if I'm using it right. Where do I add :release-stubs #{cljs.test} — in :build-options for the (single) build I'm using, or under :release? Or under :release :build-options? It doesn't seem to take effect (I am using 3.0.5).
https://github.com/thheller/shadow-cljs/blob/master/shadow-cljs.edn#L214
just top level for the build, applies only to release so can always be there
Hmm. In that case I think I have two separate problems. One is that the option doesn't seem to take effect at all when I build through my build tools which change the :build-id. The second one (once I comment out the line that changes :build-id) is:
Execution error (ExceptionInfo) at shadow.build.cljs-bridge/error (cljs_bridge.clj:173).
Invalid :refer, var cljs.test/deftest does not exist[clojure.test :as test :refer [deftest is]]ah doh. that relies on the implicit aliasing of clojure.test -> cljs.test
the stub is only for cljs.test so thats a problem
Yes. So do I need to go and conditionalize this all over the place?
try the manual approach first :release {:build-options {:ns-aliases {clojure.test cljs.test-stubs}}}. that should be ok?
didn't consider this auto alias stuff, may need to adjust how this works a little bit
So that works and is mind-boggingly amazing in its awesomeness. It drops >110kB of JavaScript that would need to be parsed on initial startup.
I do use 3.0.4, thanks.
I'll ask in #clojurescript as well, just so that this gets some visibility — I'm pretty sure many people are unaware of this problem.
maybe I should add a "standard" solution in shadow-cljs directly? cljs.pprint is a common problem, but it is kinda hard for shadow-cljs to tell if you actually use it in prod mode anywhere. so would be behind an option for sure. cljs.test I always relied on tests being in separate files personally, but might as well mock that out too.
https://code.thheller.com/blog/shadow-cljs/2025/05/07/dealing-with-zombies.html
yeah, best to not require it. many things can't be removed reliably. build reports shows what required cljs.test, try to move it somewhere not included in the build
Well, almost everything seems to require cljs.test, because I have my deftest forms in my source files, so there is a (:require [clojure.test :as test :refer [deftest is]]) in almost every file. I somehow thought this would all get auto-removed, since none of the tests should actually be included. pprint+test is almost 110kB of JavaScript, that's significant.
I wouldn't want to move my tests out to a separate directory structure, it makes them less accessible, easily forgotten, and they stop working as documentation…
doesn't need to be a separate directory structure, just a foo.bar and foo.bar-test in separate files in the same folder
tests themselves are removed, but not the cljs.test code itself
there used to be an option for forcefully remove some stuff, but the closure compiler team removed it without replacement
:ns-aliases could be used to just replace the implementation with dummy code, a bit annoying since macros are involved but doable
Well, I don't want my tests away from the functions, so I will need to mess with :ns-aliases I guess. I have to figure something out, 110kB of overhead because significant after I implemented code-splitting and other optimizations, all enabled by shadow-cljs 🙂
if you mess with aliases make sure you are on 3.0.4. there was a recent bugfix involving that feature
I would appreciate that, we've encountered the same.
I'm completely convinced of the argument for not needing :source-paths (https://code.thheller.com/blog/shadow-cljs/2018/02/08/problem-solved-source-paths.html), but having a convenient way to pprint in dev/test while keeping deployed artifacts small would be great. For now, we've implemented our own (slightly sad) subset of pprint. 🙂
Well, being able to just flip a switch to drop 110kB of JavaScript from my release versions would be very useful. And just to clarify: there is rationale for keeping tests with the functions. In my case, apart from being better maintained, they also serve as additional documentation with examples.