Fork me on GitHub

Is there a way to decrease the size of an app built and served by shadow-cljs in dev mode? We’re only a few pages into our app and the payload in dev is already over 15MB - well over half of that is cljs core and uncompressed 3rd party deps. There’s also an issue regarding the sheer number of http requests required to deliver code this way, I’m seeing hundreds of requests for the category of code described above, this makes testing on a mobile or in browser emulation tools very slow


@nick828 Is turning optimizations on out of the question?


@tomi.hukkalainen_slac I don’t believe that is recommended in development for compilation time reasons


You could try how bad it is


Testing and pure development are a bit different, so it might be better still to do even :simple for those mobile test runs


@tomi.hukkalainen_slac That’s a fair point, not ideal but a workaround that I can live with


When starting an embedded shadow-cljs from clj (with a deps.edn only containing the dep on shadow 2.4.20), the :source-paths in shadow-cljs.edn seems to be totally ignored. Can I convince the embedded shadow to use the source paths in shadow-cljs.edn instead? I tried :deps false without success. (I can setup an alias in deps.edn, but I’d rather have the cljs stuff in the shadow config and the clj stuff in deps.edn)


Related to nijk's question, is there a nice way to analyze/visualize the shadow bundle content sizes, similar to or


@tomi.hukkalainen_slac answer is yes, how, I forgot. Start the server and type some command. Sure someone here will tell you. There’s I think a blog post from thheller on how to do it.


Thanks for the hints. I'll go hunting in google and in the blog


That last comment shows the same report I get with so I guess no pretty graphs for now, unless I build it myself.


Can't be assed, the list is good enough

Yehonathan Sharvit14:07:36

@thheller I was offline for 2 days

Yehonathan Sharvit14:07:44

Back to the issue that I have with aws-sdk

Yehonathan Sharvit14:07:57

Here is my error:

➜  shadow-cljs-app git:(master) ✗ shadow-cljs watch browser
shadow-cljs - config: /Users/viebel/prj/shadow-cljs-app/shadow-cljs.edn  cli version: 2.4.5  node: v10.6.0
shadow-cljs - updating dependencies
shadow-cljs - dependencies updated
shadow-cljs - starting ...
[2018-07-18 17:02:28 - WARNING] TCP Port 9630 in use.
[2018-07-18 17:02:34 - WARNING] failed to start :browser dev-http:8025 reason: Address already in use
shadow-cljs - HTTP server for :browser available at 
shadow-cljs - server version: 2.4.5
shadow-cljs - server running at 
shadow-cljs - socket REPL running on port 49168
shadow-cljs - nREPL server running on port 49170
shadow-cljs - watching build :browser
[:browser] Configuring build.
[:browser] Compiling ...
[:browser] Build failure:
The required JS dependency "util" is not available, it was required by "node_modules/aws-sdk/lib/event_listeners.js".

Searched in:/Users/viebel/prj/shadow-cljs-app/node_modules

You probably need to run:
  npm install util


Yehonathan Sharvit14:07:38

I have created a public github repo that reproduces this issue. Here it is:


@viebel you need to add shadow-cljs itself as a npm dep. npm install --save-dev shadow-cljs that will install the missing util polyfill

Yehonathan Sharvit19:07:52

Awesome. It worked. I missed this part in the documentation


@nick828 I'd look into trying to reduce the deps a bit. 15mb is a bit excessive and will still probably be huge in :advanced release builds. beyond that gzip + http2 can help reduce load times in dev


@niclasnilsson shadow-cljs completely relies on the JVM classpath so whatever you use to manage that is responsible for including the source paths. shadow-cljs can't add any paths after startup.


@tomi.hukkalainen_slac I played with various visualizations but none of them were even close to the simple table view in actual visible information


still want to add some complementary graphs at some point though


Hello, first time user of shadow-cljs and trying to run the “conduit” example from the main repo (as it matches as close as possible what I need to do) to adapt my workflow to it. Everything yet works, except that if I change the source code (of a reagent component from the demo), shadow-cljs says that it compiled without errors, the browser then tries to reload it, but then throws an error in its console:


env.cljs:174 error when calling lifecycle function conduit.core/main Error: Target container is not a DOM element.
    at module.exports (invariant.js:43)
    at legacyRenderSubtreeIntoContainer (react-dom.development.js:17239)
    at Object.render (react-dom.development.js:17318)
    at Object.reagent$dom$render_comp [as render_comp] (dom.cljs:20)
    at Function.reagent.dom.render.cljs$core$IFn$_invoke$arity$3 (dom.cljs:44)
    at Function.reagent.dom.render.cljs$core$IFn$_invoke$arity$2 (dom.cljs:39)
    at Function.reagent.core.render.cljs$core$IFn$_invoke$arity$2 (core.cljs:74)
    at conduit$core$main (core.cljs:75)
    at shadow.cljs.devtools.client.env.make_task_fn (env.cljs:171)
    at shadow$cljs$devtools$client$env$do_js_reload_STAR_ (env.cljs:180)
shadow.cljs.devtools.client.env.make_task_fn	@	env.cljs:174
shadow$cljs$devtools$client$env$do_js_reload_STAR_	@	env.cljs:180
(anonymous)	@	env.cljs:180
(anonymous)	@	env.cljs:209
shadow$cljs$devtools$client$env$do_js_reload_STAR_	@	env.cljs:180
shadow.cljs.devtools.client.env.do_js_reload.cljs$core$IFn$_invoke$arity$4	@	env.cljs:216
shadow$cljs$devtools$client$browser$do_js_reload	@	browser.cljs:66
(anonymous)	@	browser.cljs:151
(anonymous)	@	browser.cljs:100	@	@	@	@	@	@
XMLHttpRequest.send (async)	@	@
shadow$cljs$devtools$client$browser$load_sources	@	browser.cljs:92
shadow$cljs$devtools$client$browser$handle_build_complete	@	browser.cljs:151
shadow$cljs$devtools$client$browser$handle_message	@	browser.cljs:267
shadow$cljs$devtools$client$env$process_ws_msg	@	env.cljs:148
(anonymous)	@	browser.cljs:327


(I changed the dependency in the example source to use the latest 2.4.21 version of shadow-cljs)


With the “conduit” example I mean the example source from


anyone have working with shadow?


@eoliphant One coworker is playing with it, but not with shadow. I guess he has just a dist bundle with global assignment or something. Any particular problems?


nah, was just curious about to give it a whirl


there’s apparently a cljsjs bundle for it already


I lost interested after he told me you need to run your separate less build anyway to change the style. So I went for material-uiV1 instead (from V0)


I see, perhaps he's then using that


and someone has a wrapper for it as well


yeah i just like it because it’s pretty complete lol


MUI got a lot of flak from being difficult to customize, but I think their choice to use JSS is the best one, from the modern options I'm aware of


(I mean the old version was rightfully criticized for that, but the new one has JSS)


ill check it out. i’m more of a backend guy. so i tend towards stuff that gets most of the way there, then someone else can come theme , etc


now i’m looking at MUI agian.. looks prety cool. especially the pro thanks for confusing me lol lol..


@plamen that usually happens when using goog.History for some routing purposes and reloading the file that initializes it. the conduit code has that issue. the hook-browser-navigation! should only be called once.


Can I set :deps :aliases on a per build basis?