Fork me on GitHub
Oliver George02:10:00

I'm looking for the shadow-cljs.edn equivalent of


Oliver George02:10:51

So that it's behaviour is controlled by the :builds selection

Oliver George03:10:12

Perhaps I'm unduely cautions. It doesn't seem to be used unless the NS is refrerenced. (I worried two conflicting ns would cause confuse)


dev-http server has to be running or css reloading doesn't work for me. Just want to mention it.


It doesn't. You just need to set :watch-dir when using custom servers as described in the docs


Yeah I did exactly that last night and it didn't work. Somehow it's working this morning. :thinking_face:


@thheller I can confirm that upgrading the jdk version in CI fixed the OOM error. thanks again for the heads up


After setting up a web worker per this tutorial (, I observed that the worker is making a waterfall of loads, each is a separate request to a namespace. Isn't this not ideal? Why couldn't it get these from the shared.js?


@zhuxun2 this is only during development. a release build will just load the shared file

Roman Liutikov11:10:35

Given the following modules config

{:shared {:entries []}
 :a {:entries [a.entry]
      :depends-on #{:shared}}
 :b {:entries [b.entry]
      :depends-on #{:shared}}}
What could be the cause of this build error?
Module Entry "b.entry" was moved out of module ":b".
It was moved to ":shared" and used by #{:shared :b}.


@roman01la something in the :shared or :a module directly requiring the b.entry ns. can't have that without either removing that require or making b depend on a

Roman Liutikov12:10:23

hmm, interesting, I don’t see any usage of b.entry apart from in modules config


well it doesn't have the to be the entry directly. can be a -> c -> b

Roman Liutikov12:10:35

hm, are you saying that if the entry ns is app.b.entry (that is not required anywhere) then requiring app.b in :shared will cause app.b.entry to be moved into the shared module? Does that mean that NS names hierarchy can impact how code splitting works?


@roman01la no, not at all. the hierachy does not matter at all. only the literal ns. in general the entry namespaces should not be directly required anywhere

👍 1

use something like if you need to lazy reference code from the entry namespaces


just a direct require in ns is not allowed, indirect and lazy is fine


by a -> c -> b I meant a.entry requires something.c which requires b.entry thus forcing b.entry to be moved since its supposed to be in :b but can't


if it were allowed to be moved out then :b would end up empty and pointless


I’m trying to do a little demo showing shadow-cljs capabilities and as a part of a demo I’m installing an npm package, requiring it and rendering a view from it. Namely it’s react-calendar. But it seems like shadow does not pick up css automatically and I’m getting quite ugly calendar. Is there a way to solve that rather than including css directly to the index.html?


shadow-cljs does not support processing css


@thheller is there any preferred way to process css?


that is entirely subjective 😛 I use tailwind-css similar to this setup some older projects of mine use node-sass


or if you intend to use many packages that basically expect webpack (by directly using css) you can just use webpack as described here

Andrew Lai20:10:56

Hi guys! I'm new to shadow-cljs, and working with shadow-cljs through a custom build pipeline in our monorepo. I'm getting an error when compiling, IOException: Cannot run program "node" I am still doing some research to figure out exactly how the build is being called and help refine this question, but do you have any suggestions for how to interpret this error? It seems like shadow expects to find a node executable somewhere, but it isn't finding the executable. Does node need to be in the same directory?


you need to have installed yes


on the system path is enough, like any other executable. doesn't need to be in a special place

Andrew Lai20:10:59

Thank you! We are doing a special build process through Bazel, which may run in a sandboxed environment, so I think that's the next thing I'll check for. I'm wondering if Node isn't being installed properly in the sandboxed environment.


never used bazel personally but other people have used it with shadow-cljs so it works in some way I guess :P