This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2023-08-21
Channels
- # announcements (1)
- # beginners (30)
- # calva (3)
- # cider (23)
- # clerk (5)
- # clj-kondo (16)
- # clojure (39)
- # clojure-brasil (3)
- # clojure-europe (19)
- # clojure-nl (1)
- # clojure-norway (54)
- # clojure-seattle (1)
- # clojure-uk (2)
- # clojurescript (9)
- # cursive (3)
- # datahike (13)
- # datomic (4)
- # emacs (7)
- # events (1)
- # fulcro (32)
- # hyperfiddle (17)
- # jobs-discuss (3)
- # meander (5)
- # missionary (132)
- # music (2)
- # nyc (1)
- # off-topic (33)
- # polylith (22)
- # proletarian (3)
- # scittle (106)
- # shadow-cljs (23)
How does shadow resolve build targets to the ClojureScript's compiler target? That is to say, how are transformations like :target :browser
-> cljs.core/*target* "default"
determined? I know I can manually try each build target, but is there documentation, either on shadow or cljs side, that explains the "targets" CLJS itself recognizes? I was able to find default
, nodejs
, webworker
, and nothing else.
cljs.core/*target*
is in no way related to what :target
means in shadow-cljs, that is an entirely different thing
I'm getting a closure compiler error when trying to use an npm library:
Closure compilation failed with 4 errors
--- node_modules/@grame/faustwasm/dist/cjs/index.js:908
Dynamic import expressions cannot be transpiled.
--- node_modules/@grame/faustwasm/dist/cjs/index.js:915
Dynamic import expressions cannot be transpiled.
--- node_modules/@grame/faustwasm/dist/cjs/index.js:916
Dynamic import expressions cannot be transpiled.
--- node_modules/@grame/faustwasm/dist/cjs/index.js:934
Dynamic import expressions cannot be transpiled.
how do I address this? I'm a bit confused as to why this is even happening as I thought from reading the user guide that the closure compiler wasn't even involved except during release builds, but this is happening during a watch build.shadow-cljs uses the closure compiler to process npm packages so they can be loaded in the browser properly
unfortunately some use features that the closure compiler doesn't support, this being one of them
all depends on what the closure compiler does really. nothing I can easily influence from the shadow-cljs side.
I mean look at the code, relying on a comment to tell webpack to leave something alone stink to high heaven to me
FaustModule = (await import(
/* webpackIgnore: true */
jsFileMod
)).default;
to be honest the JS world needs to figure this shit out. once they do we can see about implementing it
I have no insights on the direction of the closure compiler in general, so I make no plans until I see something implemented
is there any kind of workaround for cases like this? Like some way to make it so the library just isn't processed by the closure compiler?
you can use webpack to process everything via https://shadow-cljs.github.io/docs/UsersGuide.html#js-provider-external
Compiling it with webpack and including that rendered/compiled result into CLJS environment, maybe? I’m just using my imagination.
ah, perfect! switching to :js-provider :external
seems to have made it work, thanks
well, shadow-cljs then just doesn't do any npm processing. you still need to setup webpack and stuff :P