I’m observing something weird when using specs to validate a reagent atom — should I be careful when importing namespaces only for side effects (that is, to register specs etc)?

My app.main (entry point) requires my app.state (and uses a bunch of functions) which in turn requires my app.spec — and uses nothing from there. However I get an error like so

main.js:3045 failed to load app.state.js Error: Unable to resolve spec: :base/count
    at Object.cljs$spec$alpha$the_spec [as the_spec] (alpha.cljs:121)
    at Function.eval [as cljs$core$IFn$_invoke$arity$5] (alpha.cljs:518)
    at Function.eval [as cljs$core$IFn$_invoke$arity$4] (alpha.cljs:513)
    at Object.cljs$spec$alpha$def_impl [as def_impl] (alpha.cljs:314)
    at eval (state.cljs:120)
    at eval (<anonymous>)
    at Object.goog.globalEval (main.js:2188)
    at Object.env.evalLoad (main.js:3043)
    at main.js:3261

Where :base/count is defined in app.spec like so (s/def :base/count (complement neg-int?)) — and if I put that declaration in my app.state ns, the problem goes away.

It’s my first time using spec from CLJS, so perhaps shadow CLJS might not be the culprit. I’m using :loader-mode :eval if it makes any difference.

OK, got it — I had two shadow-cljs builds running — one for running the tests in node, one for the browser. Stopping them both and running only the browser one seems to fix things, :loader-mode :eval still works.

Ouch, adding cljs.spec to the project hits me with a 60kb of optimized javascript. I guess DCE isn’t working in this case?

@orestis yes spec is never DCE'd

Bummer.

I opened https://dev.clojure.org/jira/browse/CLJS-1701 a while ago but nobody seems to care 😛

Voted 🙂 — is there a workaround?

nope. note that the 60kb is pre-gzip. gzip'd its not so bad.

Yeah, but still, 20kb of gzip was like a 15% increase of my build. I’m not dying, but would be good to fix.

can't really fix it. can maybe reduce it a bit but also not by much.

only fix is not importing spec in the first place

Yeah, I guess I can do that — but eventually I’d like to actually validate some things at runtime.

then there is no way around it anyways

Could be that the reason it’s not fixed yet is that people actually use it at runtime and gladly pay the price. I was a little bit surprised to see the gen.test stuff in there.

it really cannot be fixed in the way it is written right now. so you basically need to rewrite the entire thing

but that still doesn't guarantee that code can actually be removed

@thheller I have to thank you (again) for coming up (and maintaining) shadow-cljs. It’s a fantastic tool. Please apply for Clojurists Together again.

@thheller looking into now builders, wondering if shadow-cljs supports all requirements to make one? https://zeit.co/docs/v2/deployments/builders/developer-guide/

how can i ensure i’m not running two versions of react at the same time?

i am already using :exclusions [cljsjs/reac cljsjs/react-dom]

and importing react from npm

in shadow-cljs, React won’t be loaded from cljsjs whether you exclude it or not

what’s your package.json look like?

and are you loading any other bundles on the webpage you’re running your CLJS code?

Has anyone used shadow-cljs with single-spa?

@mateus.pimentel.w shadow-cljs ensures that cljsjs is not used. so no need to worry about including it.

@leocardosoti many people do yes

I'm coding two very different but related builds with different package.json files: one a :node-library running Google Cloud Functions, and one a browser app that communicates with those functions via Firebase. I'd also like to share some common code between them. Is there a way to specify different package.json files per build in one shadow-cljs and build these both from one shadow-cljs server run, or is it best to run two separate shadow-cljs instances?

Also, is there a way to run a watch on a node-library and prevent the repl and websockets stuff loading? It's causing errors in the local firebase cloud functions emulator. I'm only able to get release builds to work with it, and it'd be nice to just have the release build get triggered when the code changes, but otherwise have it be exactly the same code as a release build.

@thosmos what I recommend doing is keeping a dedicated directory for your node builds/packages

something like https://github.com/thheller/shadow-cljs/tree/master/packages

so each npm package gets its own directory with its own package.json

and the CLJS isn't kept in that directory at all. the compiler output just goes there

@thheller https://single-spa.js.org/

eg. https://github.com/thheller/shadow-cljs/blob/master/shadow-cljs.edn#L27-L36

@leocardosoti oh. didn't realise that is a framework. no not aware of anyone using that

i mean the single spa framework

ahhh

ok

@thosmos what kind of issue do you get with the functions emulator? you can just disable the websockets stuff with :devtools {:enabled false} (like in the above config)

ah yes I just saw that in your example, but I missed it in the manual

The emulator error is

error: SHADOW import error /Users/thomas/Develop/take2/experiments/threshold-functions/functions/.shadow-cljs/builds/gcf/dev/out/cljs-runtime/shadow.js.shim.module$ws.js
...
Error: Cannot find module 'ws'

npm install ws?

ah, now it's working with :devtools {:enabled false}

I'm still getting an error firebase > error: no "source-map-support" (run "npm install source-map-support --save-dev" to get it) but I think I remember a shadow config to disable source-maps

ok, :compilar-options {:source-map false} fixed that, so now it's working great! Wow, I'm so impressed with shadow-cljs Thank you!

you may have more luck with :npm-module instead of :node-library if the emulator is so picky