This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # babashka (2)
- # beginners (51)
- # calva (79)
- # cestmeetup (1)
- # chlorine-clover (1)
- # cider (6)
- # clj-kondo (1)
- # cljdoc (4)
- # cljsrn (2)
- # clojure (31)
- # clojure-europe (2)
- # clojurescript (5)
- # conjure (4)
- # cursive (26)
- # datascript (4)
- # datomic (1)
- # figwheel (1)
- # figwheel-main (2)
- # off-topic (25)
- # reagent (2)
- # reveal (4)
- # shadow-cljs (21)
- # xtdb (1)
Q: I’m running a shadow-cljs browser app inside Salesforce. Using one type of integration it loads/works great. Using another I get “shadow-cljs - failed to load 34” in the console. I can see from the generated js that this is loading the npm pdfjs module. Unfortunately that is where the trail ends for me. I can’t work out why it won’t load even when I use the debugger in the fn that calls shadow.provide for that dep - it never seems to invoke that fn
even stranger is that in the first type of integration, it never calls that provide fn either but the app works ok
FYI: the integration that works is a Lightning Component and the one that fails is a Lightning Web Component. That doesn’t mean anything to cljs devs but I mention it for completeness
Hmm: I was able to catch an error in the browser debugger “”Cannot assign to read only property ‘URL’ of object ‘[object Object]’“”
I suspect the Salesforce browser security is suppressing something needed by shadow when loading the pdfjs dep
I’ve found the culprit https://github.com/mozilla/pdf.js/blob/15087c35d164a4152b21adde908b4d7619897bb3/src/shared/compatibility.js#L264
Yeah, I think you are right. Seems like some webpack trickery. I have way around it I can try. Thx
@thheller Thx! Anyway, I'll let you know, when I figured something out.
@thheller re: absolute cljs source path -- I'm transforming source code at the bottom of my namespace (so it runs whenever the namespace is loaded). it's only used for source I'm working on myself. an alternative way of getting the source code would be fine as well 🙂
Q: is the compiler option
:dump-core (https://cljs.github.io/api/compiler-options/dump-core) not supported in Shadow CLJS? It’s not listed in https://shadow-cljs.github.io/docs/UsersGuide.html#compiler-options as either supported or not, and it seems the option is not forwarded to the compiler. Is this intentional? Can I affect this through my build settings somehow?
Found the answer in https://clojurians-log.clojureverse.org/shadow-cljs/2019-07-07, that this compiler flag is not supported, and we’re supposed to use
:target :bootstrap, which doesn’t seem to work (https://clojurians.slack.com/archives/C6N245JGG/p1596225051349100).
:target :bootstrap works just fine. just some namespaces seem to cause problems. you don't have to precompile them though either.
:dump-core wouldn't do that either.