shadow-cljs 2026-06-16

I ended up using a pre-built pdfs dist file, and got it working. Thanks 🙏

I am having trouble getting Shadow-cljs and Tailwind CLI to play nice together. Tailwind "watches" the built files in :output-dir (i.e. public/js/main.js), to ensure that only CSS classes, still relevant after tree shaking, are included.

Tailwind seems to react to rebuilds of public/js/main.js, based on the output from the Tailwind CLI script, but it never recognizes any relevant changes (Tailwind class names) done by Shadow-cljs. But if I "simulates" a change to public/js/main.js by running echo ";; bg-red-200" >> public/js/main.js, Tailwind picks up the change just fine. I am curious to understand what the difference between how Shadow-cljs and file appending differs, so I can fix my problem.

One way for them to 'play nice together' is to use: https://github.com/thheller/shadow-css

for development builds the files are included as inlined strings that get eval'd. tailwind might have issues finding what it needs. instead run it over the public/js/cljs-runtime/*.js files for development

I've had Tailwind just watch the cljs sources and not care if tree shaking would remove something.

@thheller If I copy a big chunk of what I already have in main.js:

SHADOW_ENV.evalLoad("reagent.debug.js", true, "goog.provide...
...
...
SHADOW_ENV.evalLoad("app.core.js", true, "goog.provide...
into a file i.e. partial-shadow-build.txt and run partial-shadow-build.txt >> public/js/main.js Tailwind also picks up the changes just fine. But I also tried to cat copy-of-main.js > public/js/main.js and then Tailwind doesn't seem to be able to pick up the changes. I guess I have something simple and concrete to try and create a Tailwind bug report.

@juhoteperi I've also tried that first, and it works 👍 I just think there is something appealing about differentiating between dev and production as little as possible.

@cjmurphy is this: Fix issues with Tailwind by not using Tailwind?

No you can use tailwind with shadow-css, and it is the same in dev and prod. It abstracts away those tailwind subtleties. In fact when I first started to use shadow-css I thought that was its purpose (to do tailwind better). Then I found you can fallback to non-TW when for instance a utility can't be found or you need to go 'in between' two TW utility values.

Using the cljs sources for release builds also keeps the differences between release and dev lesser

@juhoteperi okay so you also build from cljs sources for production?

@cjmurphy not clear to me how that would work from the README.md. If this other thing is a dead end, I might circle back to that. Thanks.

public/js/main.js might just be a big file and tailwind watching it triggering before it is finished writing 🤷