This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-06-20
Channels
- # admin-announcements (5)
- # alda (1)
- # aws-lambda (1)
- # beginners (74)
- # boot (62)
- # cider (29)
- # cljs-dev (36)
- # cljsjs (15)
- # cljsrn (34)
- # clojure (58)
- # clojure-android (3)
- # clojure-austin (15)
- # clojure-austria (11)
- # clojure-dusseldorf (25)
- # clojure-germany (6)
- # clojure-greece (26)
- # clojure-quebec (8)
- # clojure-russia (50)
- # clojure-spec (12)
- # clojure-uk (8)
- # clojurescript (46)
- # core-async (11)
- # cursive (22)
- # datomic (2)
- # devcards (27)
- # dirac (5)
- # hoplon (109)
- # jobs (1)
- # kekkonen (2)
- # lein-figwheel (12)
- # leiningen (2)
- # microservices (1)
- # off-topic (3)
- # om (70)
- # onyx (17)
- # planck (21)
- # re-frame (3)
- # reagent (2)
- # rum (1)
- # spacemacs (12)
- # spirituality-ethics (9)
- # untangled (44)
- # vim (2)
- # yada (8)
its just a seq of symbols that correspond to namespaces that should be loaded before the main ns
no dependency management or anything like that, these things should not be order dependent
so library authors should provide (one) bootstrap namespace to be added to the list, right?
and users will be supposed to add it to their :preload
as a configuration step for their project
doing this implicitly is a possibility, but I would like to wait on that to see if :preload
works well enough on it’s own
people often setup dev stuff but they have to muck around with the classpath and requires and all that
https://github.com/clojure/clojurescript/blob/master/src/main/clojure/cljs/closure.clj#L1381
btw. if you convert it to a bunch of goog.require calls, I think the dependency ordering will be solved as well, a namespace can require its dependencies and won’t require them twice
this is really good so people can easily separate their tooling concerns from their dependency tree
I mean, cljs-devtools could require lib-x even if lib-x goes after it in the list, it would force to load it first, and subsequent lib-x require will be a no-op
I hit this problem today wanting to use cljs-devtools and realized we should just fix this once and for all 🙂
btw. is there any official naming for closure modules which pretend to be cljs namespaces? I call them in my code “pseudo” namespaces, just wondering how do you call them in cljs codebase, didn’t look for it
ok, will stick with pseudo, in my case I need to distinguish between them and do things differently