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?

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

:man-facepalming:

doh, you are correct, thanks!

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

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

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

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

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

@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

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

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.

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 ...

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.

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

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

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

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

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

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

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.

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

would be interesting to see what webpack actually does

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

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

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