{:source-paths ["src" "resources"]

 :dependencies
 [[com.pitch/uix.core "1.0.1"]
  [com.pitch/uix.dom "1.0.1"]
  [binaryage/devtools "1.0.7"]
  [com.adamrenklint/preo "0.1.0"]
  [cider/cider-nrepl "0.44.0"]]

 :builds
 {:app {:output-dir "resources/public/js"
        :asset-path "/js"
        :target :browser
        :modules {:main {:init-fn client.client/init}}
        :devtools {:watch-dir "resources/"
                   :preloads [client.preload]}}}}

I guess you could pull in some bits from shadow.resource ns, IIRC the slurp-resource fn will pull in a resources and also force compiler to rebuild and hot-load when the resource is updated

Hmm, that might work but I'd favour a more general solution because there may be other resources down the line I'm just focusing on the CSS for now. That's a good start though, thanks!

:watch-dir "resources/public" assuming the actual css files sit in resources/public/css and are served via http /css/whatever.css

that should be it for css reloading

They are, and I tried that 😕

I'll push what I have and you can take a better look

note that changing :watch-dir requires restarting the build. so it you tried stuff without restarting it wouldn't work

I figured and I did. maybe I didn't then...

Alright well idk what I did but it's working now -_- Thanks for the 🦆 😅

log output goes to where the shadow-cljs process was started. could be that is hidden in cider or something

you likely shouldn't be using hooks 😛

I see them abused too much and used for things they were never intended to do 😛

regardless ... I'd develop them in the usual REPL workflow, reloading the CLJ namespace from the REPL and stuff

there is literally no reason to ever restart anything thanks to the REPL 😛

I don’t see the logs in the nrepl buffer. But I do see other shadow activity. Weird.

cider controls what you see at the buffers, not shadow-cljs

I'd run npx shadow-cljs server and then connect to the REPL remotely

gives you a very obvious place where things are logged and the process to be killed

It typically just logs anything I log though. I use it all the time for sure

And I definitely rely on hooks. We have several prep steps needed.

log is also kind of shadow-cljs internal, so not sure what you are using it for

don't know what that means, prep likely shouldn't be done in a hook if you ask me though

Well some of it is for convenience when starting a repl to have things get done in that single JVM step. Like building sass commands and cache busting it. But that isn’t critical and could be earlier shell steps - just more clunky to build that into something like cider-jack-in.

More pressing is that we are currently still going to be using webpack to bundle until I can see if what shadow does works for us and migrate.

I need to run the bundles after shadow compiles cljs but before the rest of the repl can be used since my webserver needs the bundle. Also it all has to be cache busted etc.

In figwheel you use the bundle target and it gives you a time to slip in the bundle command automatically after the compilation. In shadow I think I just have to use a hook.

Keep in mind I’m working with multiple people teams. And we have an easy jack in sort of flow with figwheel. So having a bunch of weird new steps for everyone isn’t ideal.

here is how I go about doing things, it is basically described in this readme https://github.com/thheller/shadow-css?tab=readme-ov-file#development-builds

I can hack a bunch at the jack-in command script too. But trying to do the least. We also have a few calva users.

basically I have a (repl/go) keybind

this starts everything I need, and restarts it when I press it again

single JVM process, can do everything

this function you write and have full control over. there is no need to shadow-cljs to call it or know what it does

that example also builds css, so should be easily translatable to sass or whatever

you can start shadow-cljs watches from the clj API, or anything shadow-cljs for that matter

would also fit very seamlessly into a jack-in workflow as far as I can tell

there is absolutely no need to have shadow-cljs do things it isn't meant to do via build hooks 😛

I’ll check it out.

I still think hooks make a lot of sense for bundles

You want to kick off the bundler as soon as the cljs compiled js is done. Ie. the flush phase

(shadow/release :app) (make-that-bundle-thing) literally two function calls

This is for dev too

And I’d have to make jack-in call of this for cider. And do something else for calva. Etc.

I generally do cache busting things only in release builds, no need for it in dev

We use the same webserver infrastructure.

It expect the same cache busting setup. Doesn’t know about a “dev setup”

So it was just easier this way.