Fork me on GitHub
eccentric J11:09:59

Working on a small greenfield project for work. Mostly a static pricing application. I would like to hash various assets like images and css files but I'm not sure on the best way to accomplish that with shadow. Was thinking a build hook might be interesting, or compiling to esm and using esbuild to bundle but not sure shadow will like importing image files, perhaps best to have an nbb script run before each build to generate a bundled edn file that points the common name to an asset version path? Any better ideas or examples out there?

eccentric J11:09:41 found that which might work but not sure that solves the problem for assets that need to be dynamically rendered from React


IMHO shadow-cljs doesn't need to know about any of this and shouldn't be involved at all


you build your CLJS normally and feed the asset data into it at runtime


either via the HTML or by having your output load a .json file or so

eccentric J05:09:01

I see. That's the strategy I was leaning towards, generating an edn file included with the build to point to assets but after exploring frameworks like remix, directly importing assets is nice because it only needs to generate hashes\optimize resources referenced vs generating a manifest by hashing all asset files. Alternatively, might be able to reach a reasonable middleground by scanning the cljs code for refs to asset paths and only generating assets for those, somewhat inspired by how tailwind figures out what classnames to define in the compiled css file.


after a few beers i accidentally accessed the nrepl port (localhost:8777) in a browser, which resulted in an arithmetic exception (long overflow). just thought i'd let you know

🍻 2
Lucio Assis10:12:52

So today I learned that you get the same exception if you're in Cursive and mistakenly connect to shadow's nrepl but the cursive repl config says Connection Type = Socket REPL Just leaving this here in case someone comes across long overflow trying to start a cljs repl via Cursive.

👍 2
Petrus Theron13:06:00

Thanks, @U028ZNM1S13 I managed to find the same issue. Have commented solution on this long-standing issue on nREPL repo:

thanks2 2

hello, what config can I set so shadow-cljs stop preventing reload on deprecate warnings?


a bit more info: I'm adding cljs tests to a library, the tests do call deprecated functions, but that's an OK situation here, we want the fn to be deprecated, and still want to test it, is there a way to ignore all deprecation calls? or tune the tests namespaces to ignore them?


:warnings-as-errors search for it in the user guide there is a link to the list of possible values


but I guess that's to do the opposite of what I want no? this seem to be a way to raise the warning and behave as an error, I want to ignore instead


set it to false


actually my bad, i have :ignore-warnings true instead in the :devtools section so that's probably this one


not sure how to ignore for a single warning type though


:compiler-options {:fn-deprecated false} to get rid of them

gratitude 1

:devtools {:ignore-warnings true} to ignore them for hot-reload purposes

gratitude 1

just an errata for anyone looking at that in the future, to disable the deprecate warning, this is the config:

:compiler-options {:warnings {:fn-deprecated false}}