This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-10-25
Channels
- # aws (2)
- # aws-lambda (2)
- # beginners (95)
- # boot (47)
- # cider (13)
- # clara (5)
- # cljs-dev (36)
- # cljsjs (9)
- # clojure (51)
- # clojure-austin (1)
- # clojure-greece (25)
- # clojure-italy (4)
- # clojure-japan (10)
- # clojure-russia (13)
- # clojure-spec (61)
- # clojure-uk (25)
- # clojurescript (26)
- # core-matrix (5)
- # cursive (8)
- # data-science (7)
- # datomic (43)
- # dirac (2)
- # emacs (8)
- # events (3)
- # fulcro (17)
- # graphql (29)
- # jobs-rus (4)
- # lambdaisland (4)
- # lein-figwheel (3)
- # leiningen (60)
- # luminus (15)
- # lumo (8)
- # mount (3)
- # off-topic (28)
- # om (22)
- # onyx (115)
- # other-languages (6)
- # pedestal (5)
- # re-frame (41)
- # reagent (12)
- # ring-swagger (12)
- # shadow-cljs (127)
- # unrepl (27)
- # yada (5)
Hmm, previously Closure added goog.provide/goog.require calls to the processed modules, and we parse the start of the file for those so we get dependency information for those modules
But Closure no longer adds those goog.provide/require calls
This is the place that is broken with Closure snapshot: https://github.com/clojure/clojurescript/blob/master/src/main/clojure/cljs/closure.clj#L2390
@juhoteperi does that change appear intentional and is there some kind of rationale?
There was a PR which mentioned this... sec
https://github.com/google/closure-compiler/pull/2641 > ES6 and CommonJS modules no longer generate synthetic goog.require and goog.provide calls.
Maybe there is a alternative way to ask for the deps and name of the module, instead of parsing them from the file
@juhoteperi but what happens to the import statements then?
Hmm. If we have the information, we can write proper deps file... but I'm not sure if those calls are required to run the JS code in browser in dev
k, so I think that’s the main issue we’ll need to address, we may need to use Closure to parse the deps in the ES6 source files?
Or maybe Closure already knows the requires etc. and we just need to ask for them when we get the processed source
CompilerInput has getRequires method
Not sure if that is correct for this case but I'll investigate and test
I think we'll need to add this pass: https://github.com/google/closure-compiler/blob/master/src/com/google/javascript/jscomp/FindModuleDependencies.java#L43
But for some reason I have problems using that
Oohh, the constructor is not public...
but compiler.parse
might already run this pass
Probably, but the names would need to converted to the format closure uses module$absolute$file$path
or such
Hmm, there are cases where we don't use module-deps
, like :es6/:common-js modules outside of node_modules
Ha, success, got input.getRequires
working, needed to add this option to the compiler: (.setDependencyOptions (doto (DependencyOptions.) (.setDependencySorting true))))
Looks like ModuleNames/fileToModuleName
is enough for convert-js-modules
part, but analyzer breaks also
Due to missing symbol checks, :js-module-index
etc. are correctly updated, but I think ::namespaces
is not