not with shadow.lazy/loadable as of now since that assumes shadow.loader will do the actual loading

but I guess you could take the existing shadow/lazy.clj+cljs and modify it to use esm import instead

Got it, thanks. So I'm correct that shadow.lazy isn't intended for use w/ :esm?

this would be the part that needs chaning I guess https://github.com/thheller/shadow-cljs/blob/master/src/main/shadow/lazy.cljs#L31-L65

correct, shadow.lazy is meant for :target :browser

Thanks, will look into that option

Related to the above, is shadow.esm/dynamic-import only intended for use with the :esm target?

correct, in can in theory work elsewhere but is not currently setup to do so. basically it only exists to work around an issue where the closure compiler yells at us for using js/import directly in code

Is it possible to import es modules when using :browser target, or would that require code changes/a separate namespace from shadow.esm?

I hope it becomes unnecessary at some point

well look at that namespace. there is no code to change 😛

hahaha yeah, just checked. Thanks, I'll just do something similar to what you're doing in my own code.

the issue is that the closure compiler doesnt like dynamic import in the code and will fail

so, we call shadow_esm_import instead of import, and then prepend window.shadow_esm_import = function(x) { return import(x); }; to the code AFTER closure the closure compiler is done

Makes sense.

and currently this prepend is only done for :target :esm, so other targets just get a var not found error

Seems like it would be possible for me to give you a PR that adds that code when shadow.esm is used anywhere in the project, right? Then dynamic-import could support other build targets.

again, this is a hack that I hope becomes unnecessary. I don't really want to "spread" it further

gotcha

and you can do it yourself

in the build config :modules {:main {:prepend "window.shadow_esm_import = function(x) { return import(x); };" :init-fn ...}}

then you can use shadow.esm/dynamic-import just fine. assuming you are still in a browser of course, otherwise you might need to adjust the snippet

That's perfect, thanks. Would you take a PR for the user guide describing this stuff in a bit more detail so that when I revisit this code in 6 months I have a place to look to understand what's happening?

sure

I put something together with a pre-compilation build hook that reads the build id and spits a file into the src for the given build

I consider this a horrific anti-pattern and it is therefore not supported out of the box

do you have a specific example of why you'd want to do that?

in general the shadow-cljs builds ONLY include what they required, so if you have different builds each build would get its own entry namespace. that namespace you can use to setup build specific things since the others won't include it

https://code.thheller.com/blog/shadow-cljs/2018/02/08/problem-solved-source-paths.html

https://gist.github.com/thheller/fa044450a6470fdd1afdbcf3f37a65e3

Thanks for the help — I’m trying to port an old lein/figwheel project and that project used build-specific :source-paths to bring in a namespace to the build which contained config. I’ll try out the options you mentioned