@roklenarcic they are old and deprecated. https://shadow-cljs.github.io/docs/UsersGuide.html#dev-http should be used instead.

I seem to have trouble loading shadow-cljs 2.17.x - it complains at load time and points to potential dependency clashes, but I can't see anything out of the ordinary.

well what happens?

that is indeed a dependency conflict

guava to be exact

hrumph

Is shadow-cljs using guava then? Clojure -Stree doesn't think so...

shadow-cljs is not. the closure compiler is.

they changed how they bundle stuff so the closure compiler doesn't declare the guava dependency correctly anymore or something

but it is still used and required

I generally strongly recommend keeping your CLJS and CLJ dependencies separate for this reason

Bah. We depend on having them together.

there is an open issue about this https://github.com/google/closure-compiler/issues/3896

I don't even know which guava version it wants anymore

In the sense that some of our cljs macros depend on our Clojure code. So naturally we had everything under one JVM. Would you suggest to use two different JVMs for this? Then I guess we could at least minimize the blast radius.

one jvm is fine if you are willing to sort out your dependency conflicts

two usually avoids them completely and is easier to maintain in some sense

its usually not that hard to sort out the conflicts. just an exclude or two

or just manually depend on whatever the current guava version is

datomic or whatever is using guava is usually fine with a newer version

the closure compiler just isn't fine with an old version

Hm I will use https://github.com/google/closure-compiler#guava-libraries as a reference version and report back.

They say 31.0.1

We have an app that uses lazy module-loading, deployed to users for the very first time this past Friday w/ shadow-cljs 2.17.2 (thanks thheller for the help and documentation!). Deploy went well and without issue! Today we deployed a new version of the app, which included an upgrade to shadow-cljs 2.17.4 . Otherwise we made no changes to the build/compilation process. After the deploy, some users experienced the app crashing; in most scenarios, refreshing the app in-browser fixed things. In looking through our logs, it seemed like some of bundled modules were unable to be loaded. Multiple errors with

Error loading <module>: Consecutive load failures