Fork me on GitHub
#shadow-cljs
<
2021-10-14
>
Oliver George02:10:00

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

^:dev/always

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)

Apple03:10:01

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

thheller06:10:43

It doesn't. You just need to set :watch-dir when using custom servers as described in the docs https://shadow-cljs.github.io/docs/UsersGuide.html#_css_reloading

Apple12:10:15

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

steveb8n04:10:55

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

zhuxun204:10:36

After setting up a web worker per this tutorial (https://shadow-cljs.github.io/docs/UsersGuide.html#_web_workers), 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?

thheller06:10:15

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

roman01la11: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}.

thheller12:10:24

@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

roman01la12:10:23

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

thheller12:10:52

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

roman01la12: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?

thheller12:10:46

@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
thheller12:10:34

use something like https://clojureverse.org/t/shadow-lazy-convenience-wrapper-for-shadow-loader-cljs-loader/3841 if you need to lazy reference code from the entry namespaces

thheller12:10:52

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

thheller12:10:55

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

thheller12:10:51

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

achikin15:10:30

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?

thheller15:10:01

shadow-cljs does not support processing css

achikin17:10:14

@thheller is there any preferred way to process css?

thheller17:10:56

that is entirely subjective 😛 I use tailwind-css similar to this setup https://github.com/jacekschae/shadow-cljs-tailwindcss. some older projects of mine use node-sass

thheller17:10:29

or if you intend to use many packages that basically expect webpack (by directly using css) you can just use webpack as described here https://code.thheller.com/blog/shadow-cljs/2020/05/08/how-about-webpack-now.html#option-2-js-provider-external

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?

thheller20:10:10

you need to have https://nodejs.org/en/ installed yes

thheller20:10:09

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

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

thheller20:10:55

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