This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-10-06
Channels
- # beginners (32)
- # boot (17)
- # cider (4)
- # clara (112)
- # cljs-dev (3)
- # cljsjs (2)
- # clojure (222)
- # clojure-germany (3)
- # clojure-greece (1)
- # clojure-italy (4)
- # clojure-losangeles (4)
- # clojure-russia (46)
- # clojure-spec (24)
- # clojure-uk (71)
- # clojurescript (78)
- # community-development (5)
- # component (88)
- # cursive (6)
- # datomic (7)
- # duct (5)
- # figwheel (2)
- # fulcro (21)
- # graphql (22)
- # leiningen (3)
- # luminus (9)
- # off-topic (1)
- # om (16)
- # onyx (46)
- # portkey (30)
- # re-frame (47)
- # reagent (5)
- # remote-jobs (1)
- # ring (12)
- # ring-swagger (13)
- # rum (1)
- # shadow-cljs (81)
- # spacemacs (1)
- # specter (33)
- # sql (2)
- # test-check (2)
- # vim (16)
- # yada (11)
@mhuebert I’m doing a bit of cleanup. shadow.bootstrap
is now shadow.cljs.bootstrap.browser
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
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
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
nah I don’t want to live-reload those, that is far too much work indeed. just triggering a re-compile would be enough.
so you have one :browser
build which is the “host” and one :bootstrap
build thats just the support files
right :bootstrap-options
basically move to {:target :bootstrap :entries ... :macros ... :excludes ... :output-dir "..."}
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
eg. when compiling I can timestamp the files and then put the timestamped names into the index
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
+ with h2
the request count doesn’t matter so the user really only downloads what is needed
:bootstrap-support
{:target :bootstrap
:output-dir "out/demo-selfhost/public/bootstrap"
:entries [demo.macro reagent.core]
:macros []}
well I could put the :bootstrap-path
option into the “host” build, rather than in code if that is useful?
(ie. if you publish a bootstrap build, it could have declared certain :resolves which it expects to be available?)
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
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