This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-05-01
Channels
- # aleph (1)
- # architecture (7)
- # aws (1)
- # beginners (52)
- # boot (3)
- # cider (27)
- # cljs-dev (9)
- # cljsrn (16)
- # clojure (82)
- # clojure-dev (75)
- # clojure-italy (14)
- # clojure-nl (11)
- # clojure-spec (10)
- # clojure-uk (31)
- # clojurescript (49)
- # core-async (13)
- # datascript (11)
- # datomic (15)
- # duct (11)
- # emacs (8)
- # fulcro (46)
- # heroku (2)
- # jobs-discuss (27)
- # jobs_rus (1)
- # juxt (25)
- # keechma (1)
- # off-topic (59)
- # om (2)
- # pedestal (4)
- # portkey (113)
- # portland-or (1)
- # re-frame (14)
- # reagent (11)
- # shadow-cljs (278)
- # vim (2)
- # yada (2)
Looking into https://dev.clojure.org/jira/browse/CLJS-2702 a little; it looks like it is trivial to recover most of the functionality by continuing to work with Closure Library private API (and while retaining compatibility with the older private API), but some of the corner cases will be a little more difficult to reach and will take more digging. If curious: https://github.com/mfikes/clojurescript/commit/7f832ec13090a495983e52c1cd3b9d02ef937447?w=1
it works because we run a module resolver that is aware of the resolution context
Ok that starts to make sense, thanks for the tip, I guess I will find it in the module-deps.js
script
Other question related to that, I wonder why the module-deps.js
is launched with node --eval
? Why don't we pass cli parameters?
@richiardiandrea I don't understand the second question, but: module-deps.js
file doesn't necessarily exist in filesystem so eval is easy way to run the code without first writing it to some file
oh got it, yeah so it is run from an in-memory string that is why
Usually the original file is inside jar and node wouldn't know about those
I though it was saved to disk first in some temp folder
thanks Juho