Fork me on GitHub
#shadow-cljs
<
2020-02-04
>
genekim05:02:27

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 http://goog.net, 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!

genekim05:02:06

PS: Here’s a link to the issue I’m working out of: https://github.com/r0man/cljs-http/issues/126

thheller09:02:41

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.

thheller09:02:18

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

thheller09:02:49

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

thheller10:02:58

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

genekim16:02:52

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…

genekim16:02:28

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

thheller16:02:01

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

genekim17:02:39

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. 🙂

Eliraz07:02:05

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

orestis08:02:15

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.

orestis08:02:41

This involves a file loaded through the shadow resource api.

thheller09:02:47

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

orestis09:02:05

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

mkarp17:02:03

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?

thheller17:02:32

@me1676 no that is not possible

😞 4
thheller17:02:53

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.

thheller17:02:32

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.

lilactown19:02:11

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

lilactown19:02:30

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

thheller19:02:38

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

lilactown19:02:26

[:builds :app :devtools]

lilactown19:02:42

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

thheller19:02:06

in the build config

thheller19:02:10

(works fine for me)

J21:02:41

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

thheller21:02:12

not currently