shadow-cljs

https://github.com/thheller/shadow-cljs | https://github.com/sponsors/thheller | https://www.patreon.com/thheller
2020-11-12T12:31:11.492300Z

Hey all - I'm in the process of code splitting our single file js into multiple modules. Using the loader works on the home page, as loader/load "module" fetches /js/module.js, however if I load any other page (say /foo/bar) loader/load "module" tries to fetch /foo/js/module.js. How can I ensure that the asset path remains consistent regardless of the url?

thheller 2020-11-12T12:32:58.492700Z

set the correct :asset-path "/js" in your build config. looks like you have :asset-path "js"?

2020-11-12T12:42:37.493100Z

:man-facepalming:

2020-11-12T12:42:45.493400Z

doh, you are correct, thanks!

jkent 2020-11-12T14:16:19.496100Z

Can I tell shadow to watch certain npm dependencies? I’ve used yarn link to create a symlink between my cljs project and a js library but shadow is not picking up the new changes to the js library when it recompiles

thheller 2020-11-12T14:17:25.496600Z

shadow no longer watches any npm dependencies since that was causing issues on some projects

thheller 2020-11-12T14:17:40.497Z

you can touch the package.json of the package to trigger a recompile though

thheller 2020-11-12T14:18:10.497500Z

so if you do that after building the js lib it should work out

jkent 2020-11-12T14:27:11.498600Z

@thheller thanks! thats works and it much better than restarting shadow 🙂

2020-11-12T16:56:11.000700Z

@thheller just a follow up, thanks for your insigths, I was able to work around the dynamic import issue by forking the repo and turning it into static import[1], luckily that was the only instance of dynamic import in my npm deps. By looking around I noticed PR[2] in closure compiler, so I guess a support for dynamic imports is imminent upstream [1] https://github.com/darwin/use-cannon/commit/81fb03fda4aaf31b60085ece9118cb02183fce74 [2] https://github.com/google/closure-compiler/pull/3706

thheller 2020-11-12T17:00:13.001100Z

nah not really. it'll most likely just be ignored. https://github.com/google/closure-compiler/issues/3707

thheller 2020-11-12T17:01:25.002200Z

I also think it should NOT be supported. it is sort of annoying if libraries do this because they enforce code splitting on you in places where it might not actually make sense for your app.

thheller 2020-11-12T17:02:02.002800Z

sure there needs to be a way to do conditional code loading somehow but this is just one of the latest hacks in this area ...

2020-11-12T17:03:26.003700Z

I’d like to open an issue with use-cannon and persuade them not to use dynamic imports so I could eventually return to their official version.

2020-11-12T17:04:30.004800Z

Not sure if I have good arguments though, I’m not familiar with this new JS stuff.

thheller 2020-11-12T17:12:06.005400Z

well I don't really know why they are doing this so I can't say either

thheller 2020-11-12T17:12:41.005900Z

from the looks of it they do it to only conditionally load the Provider stuff when in a context with window

thheller 2020-11-12T17:12:52.006300Z

so presumably the code can also be loaded in a worker where they don't want that code

thheller 2020-11-12T17:14:05.007Z

but I don't get why there is import { ProviderProps } from './Provider' and then import('./Provider')

thheller 2020-11-12T17:14:44.008300Z

so I don't really understand what this code is even supposed to do from the bundler perspective

2020-11-12T17:16:25.009900Z

I was also wondering about that repeated ./Provider import, once static, second time dynamic, also that was causing warnings about cyclic dependencies when I was trying to compile the dist files of the package on my machine, because provider imports index again. Anyways, thanks for your points, I will ask them in an issue.

thheller 2020-11-12T17:16:30.010100Z

I'd expect webpack do duplicate content but no clue why anyone would want that

thheller 2020-11-12T17:17:00.010500Z

would be interesting to see what webpack actually does

thheller 2020-11-12T17:22:12.011300Z

hmm looks like the ProviderProps is just a type so probably a misplaced import that should be in the import type further up

thheller 2020-11-12T17:22:34.011800Z

maybe the typescript compiler removes that import later so it never gets to webpack

2020-11-12T17:26:04.012200Z

fyi, if you wanted to follow this up, please subscribe this issue: https://github.com/pmndrs/use-cannon/issues/132