This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2020-02-04
Channels
- # announcements (1)
- # architecture (18)
- # aws (7)
- # babashka (63)
- # beginners (38)
- # bristol-clojurians (1)
- # circleci (1)
- # clj-kondo (10)
- # clojars (4)
- # clojure (159)
- # clojure-berlin (3)
- # clojure-europe (4)
- # clojure-italy (7)
- # clojure-losangeles (6)
- # clojure-nl (7)
- # clojure-spec (3)
- # clojure-uk (109)
- # clojurescript (54)
- # css (1)
- # cursive (38)
- # data-science (2)
- # datascript (3)
- # datomic (14)
- # docker (2)
- # duct (11)
- # fulcro (47)
- # jobs (8)
- # jobs-discuss (3)
- # kaocha (4)
- # malli (3)
- # nyc (2)
- # off-topic (30)
- # overtone (3)
- # re-frame (17)
- # reagent (33)
- # shadow-cljs (29)
- # spacemacs (3)
- # specter (4)
- # tools-deps (13)
- # xtdb (13)
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
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!
PS: Here’s a link to the issue I’m working out of: https://github.com/r0man/cljs-http/issues/126
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
constant or something…
I’ll keep exploring #3. Maybe ask in another channel, too…
@U6VPZS1EK posted a reply here https://github.com/r0man/cljs-http/issues/126#issuecomment-581983199
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. 🙂
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.
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?
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.
I tried :devtools {:ignore-warnings true}
which seems to match the user guide, but it still won’t hot reload
I guess what I’m asking is, what is the proper place? it’s unclear from the user guide