I don’t remember the details about :npm-module problems, just that I, with your assistance, couldn’t make it to work. It was something with the entry point.

Webpack is what the vscode packager suggests that I pack my extension with for releases. And when I do that it shrinks it down from thousands of files and 20 MB. To one file of 1.6 MB.

@pez I can't remember the :npm-module problems either but it should be working fine. just may need to create one additional file manually or so. thats the part that :node-library basically does for you.

not sure what webpack does that shadow-cljs release wouldn't do?

or do you use many JS deps that need to be bundled as well? not sure how exactly vscode exts are packaged

So, in Calva, the cljs-lib is a small library, giving the TypeScript code (which is most of the code) access to some clojure facilities, like the cljs.reader and clj-fmt. The vsce packager greates a zip file with file extension .vsix, in which cljs-lib.js, created by shadow-cljs release is just one of the files. If I include Webpack in the build chain, it bundles all the js files into one, and vsce stops complaining about that I should use webpack. And the extension installs much faster and works excellently.

As for :npm-module problems. You and I really gave that a shot, back then. But we reached a point where you said, “use :node-library instead”. Which is where I am now. I can of course try with :npm-libarary again, but I don’t like the idea of spending days to again find out it won’t work. 😃

well :node-library is never gonna work with webpack during development and what you describe is easily possible with :npm-module

would help to remember why that was causing issues but I can't 😛

I think I can give it a quick try and we'll see if it works or at least what the problem is.

FWIW going through webpack is still gonna limit your development capabilities

so live reload and REPL will be questionable regardless

You're right. Which points me in the direction of trying to not use webpack for dev and only for release. Which brings me back to the question about if you think I can rely on that the release build are currently working swell.

hmm?

Yeah, so when I let webpack bundle things it works, but only in realease. In dev there are references to things in the .shadow-cljs dir that don't resolve. But, as you say, I might lose the repl and hot reload anyway with webpack, so not worth trying to solve that resolve problem.

yes :node-library will NEVER work with webpack during development

basically all targets make certain assumptions about the runtime they are gonna be using

:node-library as the name implies assumes it will be running in node which is not true if you package it with webpack first

it also assumes it can use the node runtime facilities to load code dynamically which is also not possible when using webpack

so the only thing you'd gain with :npm-module+webpack during development is that it becomes loadable

live-reload and REPL probably won't work reliably

I’ll avoid webpack for dev. And things the release build with webpack works, I can safely use that?

yes release builds are just one file and don't do any dynamic loading

hm, I am running into an obscure issue with shadow.loader in a production build. Module loading isn’t working, and I’ve determined that shadow.loader.initCalled is undefined. The problem goes away when I enable --debug mode, which makes me think maybe it has something to do with an advanced-mode name collision of some kind. I haven’t been able to reproduce locally, only when it is built on our CI server. (Just posting here in case some possible avenue to look at comes to mind, i’ll keep debugging)

do you get an actual reference to shadow.loader.initCalled in the optimized code?

I get a reference to the shadow.loader object,

it doesn’t contain an initCalled key

hmm. if I call init I do see shadow.loader.init was already called!

how do you get a reference to that object?

window.shadow.loader

yeah thats only the exported stuff

closure will have rewritten that and may have removed the property

ok. probably unrelated to the issue then.

what is the issue?

it repeatedly tries to load the same modules, and fails, only returning 1 as the error (which i believe just means ’consecutive errors`

repeated network calls for the same module:

assuming thats a 200 ok response?

yes

it may be throwing an error on load

all 200

ie throwing an exception when the code is evaluated

you can try loading the code directly without the loader

just via normal <script> tags in the correct order

makes debugging a bit easier

will try that.

oh… maybe this is a caching issue. When I load modules normally I append a hash as a query param, eg. dropify.js?v=<hash>

the module loader could be getting invalid/old versions

i’ll try a script tag without the query param to double check.

then use :module-hash-names true 😉

So, caching was indeed the issue. And using :module-cache-names was the solution.

Hey there, how do I specify what the init function is used when using :modules {:entries something.core} ?

Inside the :builds map

Anybody here?

:modules {:main {:init-fn some.core/init}}

Thanks but I want to use the entries map too

nothing stopping you from doing that

:modules {:main {:init-fn some.core/init :entries [foo.bar]}}

ohhh, thanks!

@thheller I just started using shadow-cljs today. I really like it

Is the manifest.edn needed in the release version of the build? Could I remove it or would that mess stuff up?

Is it needed to make code splitting work?

it is not needed no

okay, thanks