shadow doesn't pull in anything. your build does.

:resolve affects the build, but shadow-cljs - failed to load is a runtime error. it pulled in the correct file already, it didn't need help on that front

usually there should be the causing exception printed somewhere

graal is a shitty JS engine and I do not recommend using it. you'll have much more luck with node

Also, thanks again on the guidance such as :target :esm and :runtime :custom

well if you are setting :custom but don't actually provide any then you might as well just set :devtools {:enabled false}

ah, what will that do? shrink the output a bit?

(it all seems to work as it is, fwiw)

just disabled the devtools entirely, so in essence the same as :runtime :custom and not actually setting :devtools {:client-ns ...}

the idea behind :runtime :custom is that you can provide an implementation that can connect back to the shadow-cljs websocket and provide REPL/hot-reload

if you are not gonna do that at all anyway then just set :devtools {:enabled false}

ah, got it. I am not even trying to do anything that sophisticated (yet)

ok, will give that a try. Ty!

I didnt see any material changes good or bad, so I went forward with your suggestion: https://github.com/manetu/lambda-sdk-clj/pull/5

ty

note that its disabled for release builds anyways, so technically you don't even need that

ah, got it

:target :browser spits out an optimized form of ClojureJS as far as I understand

the output is equivalent to whatever the closure compiler emits, with some hacks employed by shadow in order to prevent npm code from going through advanced optimizations

I think you may be able to port the reagent SPA by using :js-provider :external then relying on webpack to produce UMD output this guide seems useful for that https://remarkablemark.org/blog/2016/09/22/webpack-build-umd/

Thanks for the response. If I need to go through webpack, I can have it output systemjs modules.

:browser isn't equivalent to any common JS module type, its basically custom

:npm-module is commonjs

:esm is well .. ESM

> We recommend a setup that uses in-browser ES modules + import maps (or SystemJS to polyfill these if you need better browser support). This setup has several advantages:

https://single-spa.js.org/docs/recommended-setup

so seems like :esm is the best fit?

:js-provider :external is only concerned with packages JS dependencies, so it would do nothing to integrate the CLJS code into the systemjs model

technically there could be a :target :systemjs since that is what this whole target abstraction is for, "wrapping" outputs to integrate into other systems. it isn't however exactly trivial to write one and I have never looked into what systemjs actually is

Thanks so much for the breakdown. Yeah, not seeing :systemjs support was not a surprise, since it's just yet another way to do modules in JS. I'll give :esm a go and hope that it's enough.

note that by default :esm will try to bundle all dependencies, for those it should not bundle you can set :js-options {:keep-as-import #{"react"}}, so that they remain as regular import and work with importmaps as the recommended setup suggests

Ah, so I don't need to do something like:

:js-options {:resolve {"react" {:target :global
                                :global "React"}
                      "react-dom" {:target :global
                                    :global "ReactDOM"}}}

nope. well, depends I guess. dunno how they are provided 😛

Thanks. That's a helpful tip.

you can also set :js-options {:js-provider :import} which will everything as import and don't bundle any npm deps

Most of my deps I'll want bundled, but the container that's running the single-spas will have react, so I'll figure out if I want :resolve or :keep-as-import for that.

seems like a core idea behind singlespa yes

Microservices have found their way into browsers. :man-shrugging: