@mhuebert I’m doing a bit of cleanup. shadow.bootstrap is now shadow.cljs.bootstrap.browser

also don’t need the cljs/js.cljs anymore, the default now works.

the question now is whether the “bootstrap host” and “bootstrap support files” should be 2 separate builds

the 2-in-1 build has a couple of issues and in theory you could share the support files on multiple builds

“host” is the build that calls init and uses load

the support files are actually just files then used by the “host”

but they don’t really need to know anything about the host

hmm

what are the issues with the 2-in-1 build?

yes the sharing of support files is a big win actually

with the way this is shaping up, one could rather simply build a service that would precompile large numbers of libraries, and put them at versioned urls cached indefinitely

the output of the “self-host” build is just a directory of files (the index, sources, all that) whereas the “host” build is going to be a typical :browser build with live-reload and so forth

yeah exactly

the issue is that currently the self-host support files are an “afterthought”

if you change one file that is not part of your actual build a re-compile will not be triggered

same for macros, since they aren’t part of the actual build they will not trigger a rebuild

the only danger with 2 builds is that you might run into issues when using different compiler versions

but even then only if there were breaking changes to the analyzer data which is pretty rare

for hosting/caching, as you allude the versioning should be by library+compiler (within ranges), this problem can be solved outside of shadow I think

I don’t think it’s worth worrying too much at this point about trying to get live reload of self-hosted-only namespaces

to me there is a big benefit in the basics just working reliably

nah I don’t want to live-reload those, that is far too much work indeed. just triggering a re-compile would be enough.

this is a huge improvement over the status quo

I’m making a new :target option now

so you have one :browser build which is the “host” and one :bootstrap build thats just the support files

ah that’s perfect, so no :bootstrap-options

which can be shared accross many “hosts”

right :bootstrap-options basically move to {:target :bootstrap :entries ... :macros ... :excludes ... :output-dir "..."}

yep

and boot/init takes a new :path where to find those files

i think we may end up revisiting the idea of a :no-follow option but let’s wait until doing real use cases and see what is actually necessary

yeah that’s perfect, so :path could be on a server somewhere

exactly, I can build-in permanent caching if you’d like

eg. when compiling I can timestamp the files and then put the timestamped names into the index

oh, excellent

so if you request cljs.core it resolves to cljs.core.123124123.js or so

this stuff can make a big difference out in the field because large asset size is unavoidable with self-host. i shed a tear at the network tab of maria

when these files can be cached forever, that concern lessens

yeah just need some proper http headers and it should cache very well

+ with h2 the request count doesn’t matter so the user really only downloads what is needed

not pre-bundled stuff where maybe 50% is unused

yup

:bootstrap-support
  {:target :bootstrap
   :output-dir "out/demo-selfhost/public/bootstrap"
   :entries [demo.macro reagent.core]
   :macros []}

looks something like this then

doesn’t need any devtools config and I just preset all the useful compiler options

since it never needs to be optimized or so anyways

could even make special source adjustments should that ever be required

the “host” build shouldn’t need any special config

well I could put the :bootstrap-path option into the “host” build, rather than in code if that is useful?

hmm

one issue though .. the :js-options :resolve would really need to be shared

hmm, maybe not

is the :macros option still necessary?

the :js-options :resolve may need to be consistent but not necessarily shared?

(ie. if you publish a bootstrap build, it could have declared certain :resolves which it expects to be available?)

may not fully understand the nuances there

i’m not quite sure what the :bootstrap-path option means. i would expect to copy the output-dir path from my bootstrap build and use that with boot/init

:macros is not needed anymore no, only for very special cases probably

the issue with :resolve is that the names are not constant, so if you configure your build to use a global for "react" you get a variable module$react in your build

but if that resolves differently in the bootstrap support files it could be module$node_modules$react$react or so

that would load 2 different reacts again

since the build provided module$react but not the other the loader would load it

but JS deps will be tricky regardless

so I think I have everything

re :bootstrap-path

if you specify it in the config you don’t need to provide it to boot/init

just a matter of where to configure it really, in code or in build config

ok pushed the update

https://github.com/thheller/shadow-cljs/blob/master/shadow-cljs.edn#L139-L159

:bootstrap-host would be your normal app which “hosts” the compiler

:bootstrap-support are the support files, all written into one directory

the shadow.cljs.bootstrap.browser ns has been updated accordingly

https://github.com/thheller/shadow-cljs/blob/master/src/dev/demo/selfhost.cljs

API is pretty much the same except for the :path option

:js-options should match for now, need to think about this more

worst case is you load everything twice, which might be bad if you host interacts with it in any way

say you detect if the returned value is something from react

watch for :target :bootstrap probably doesn’t work correctly yet

need to teach it about self-host macros first

in shadow-cljs release mode the file names will be hashed

hmm 2.1mb for the release host app with :simple, scary when used to :advanced 😉