Fork me on GitHub

Not sure where to post this… One of the things I’ve just discovered while switching a project to use shadow-cljs is that the newer version of .jsonp has a breaking change — it no longer takes a uri, but now it takes a TrustedResourceUrl. This breaks the cljs-http / jsonp library call. I’ve created a new patched version of jsonp that creates a TrustedResourceUrl, but… But it just hit me — seems like there should be a code path for the older versions of Google Closure, and one for the newer versions — how does one determine what version of the Closure compiler is being used? :thinking_face: Or to broaden the question, how do we tell which data structure to pass the jsonp function — a Uri or TrustedResourceUrl? Thank you!


PS: Here’s a link to the issue I’m working out of:


hmm yeah that is unfortunate. I also had to adjust the module loader since the closure folks switched that to the "trusted" setup as well. it is rather annoying to deal with and I don't know how to keep it backwards compatible.


unfortunately the closure-compiler version used is no longer compatible with the "old" closure-library version either


can't stay on the older closure-compiler version because of important updates for the JS support ...


but CLJS should be getting an upgraded closure-compiler version sometime soon. that will also include a new closure-library version.


Looping @U0CKBRBD2 in on this as well. Just to explore the potential decisions — this is definitely out of my league here, but I can enumerate what I think the choices are? 1. Switch exclusively to “trusted” jsonp inside of cljs-http, thus breaking anyone not using newer version of clojurescript/closure compiler. (Seems like an unacceptable choice… definitely not in spirit with Hickey-ist norms. 🙂 2. Remain exclusively with old “untrusted” jsonp, which means anyone running with newer clojusrescript/closure compilers will no longer run. (Does that mean there’s a caveat in cljs-http that says, “use only this version if running this version of clojurescript/closure?” Yuck. I’d definitely probably not read those instructions and get it wrong. ) 3. cljs-http has to determine what clojurescript/closure version is being run dynamically, and pass appropriate parameters to jsonp accordingly. (Very appealing, but I have no idea how to do this. I wish there were .versionconstant or something… I’ll keep exploring #3. Maybe ask in another channel, too…


@thheller Can you confirm or comment on my thinking? Many thanks!!!


there is no version flag or anything so comparing things would be difficult. I'm also not sure the "new" TrustedResourceUrl thing actually existed in the old version


Very cool idea of extending Uri with prototype! I’ll run with that idea, and see if I can make it work. PS: I was really “excited” to discover that Closure compiler generates compile time errors in “release mode” when attempting to do unsafe things. I actually really like static typing, although at times like this, I sure do love the escape hatches!! 😂 I appreciate the potential irony and logical inconsistency. 🙂


Hey, anyone knows about an i18n library that can integrate with hx ?


When an exception is raised during a macro evaluation, we see shadow-cljs going into a loop, trying to reload the build and hitting the same error over and over. Just a mild annoyance since fixing the problem gets you back to a stable state, just thought I’d raise it.


This involves a file loaded through the shadow resource api.


@orestis didn't I fix that a long time ago? which version do you use?


2.8.72 -- I usually lag behind releases a bit, I'll check if it happens with the latest one


Hey @thheller! I have another question. Can you please let me know if it is possible to start a npx shadow-cljs server and then start two separate npx shadow-cljs watch :app1 and npx shadow-cljs watch :app2 with different class paths?


@me1676 no that is not possible

😞 4

why would it be. swapping the classpath should never be necessary. I haven't found a good reason for it. shadow-cljs only includes what is actually used. therefore you can have a billion things on the classpath and it won't make your build larger.


every other use in the wild I have seen seemed rather random and hacky IMHO. shadow-cljs offers plenty of other options for those "hacks" if needed.


how do I get shadow-cljs to ignore warnings at dev time


I tried :devtools {:ignore-warnings true} which seems to match the user guide, but it still won’t hot reload


did you set it in the proper place in the build config?


[:builds :app :devtools]


I guess what I’m asking is, what is the proper place? it’s unclear from the user guide


in the build config


(works fine for me)


Hello 🙂 Is there a way to simulate the same behaviour of webpack I18nPlugin (replace translation on compile time) with shadow-cljs?


not currently