Fork me on GitHub
#shadow-cljs
<
2023-08-21
>
hifumi12310:08:15

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.

thheller10:08:34

cljs.core/*target* is in no way related to what :target means in shadow-cljs, that is an entirely different thing

thheller10:08:17

the node targets do set it to nodejs

thheller10:08:01

other than that it is unused as far as shadow-cljs is concerned

thheller10:08:21

I'm also not aware of any uses in cljs itself besides self-hosted stuff

Ella Hoeppner18:08:15

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.

thheller18:08:30

shadow-cljs uses the closure compiler to process npm packages so they can be loaded in the browser properly

thheller18:08:47

unfortunately some use features that the closure compiler doesn't support, this being one of them

thheller18:08:34

it also doesn't support wasm, so that would be the next problem

scknkkrer18:08:21

@thheller, if I may ask, how would you see the future of these must-have features?

thheller18:08:16

I do not see them as must have features one bit

thheller18:08:42

all depends on what the closure compiler does really. nothing I can easily influence from the shadow-cljs side.

scknkkrer18:08:25

Will Closure Compiler evantually decide it? How do you see it’s direction?

thheller18:08:41

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;

thheller18:08:09

to be honest the JS world needs to figure this shit out. once they do we can see about implementing it

🤌 2
thheller18:08:37

the wasm spec for this is still pending

thheller18:08:32

I have no insights on the direction of the closure compiler in general, so I make no plans until I see something implemented

Ella Hoeppner18:08:57

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?

scknkkrer18:08:56

Compiling it with webpack and including that rendered/compiled result into CLJS environment, maybe? I’m just using my imagination.

Ella Hoeppner18:08:31

ah, perfect! switching to :js-provider :external seems to have made it work, thanks

thheller18:08:11

well, shadow-cljs then just doesn't do any npm processing. you still need to setup webpack and stuff :P