Clojurians
#cljs-dev
<
2017-10-25
>

This page is not created by, affiliated with, or supported by Slack Technologies, Inc.

juhoteperi08:10:10

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

juhoteperi08:10:23

But Closure no longer adds those goog.provide/require calls

dnolen15:10:22

@juhoteperi does that change appear intentional and is there some kind of rationale?

juhoteperi15:10:43

There was a PR which mentioned this... sec

juhoteperi15:10:28

https://github.com/google/closure-compiler/pull/2641 > ES6 and CommonJS modules no longer generate synthetic goog.require and goog.provide calls.

dnolen15:10:36

seems like that breaks using the module processing as a pass

dnolen15:10:36

(not advanced pass)

juhoteperi15:10:19

Maybe there is a alternative way to ask for the deps and name of the module, instead of parsing them from the file

dnolen15:10:31

@juhoteperi but what happens to the import statements then?

dnolen15:10:31

hrm I guess it doesn’t matter actually

dnolen15:10:35

not for dev

dnolen15:10:48

since the dep graph is known

juhoteperi15:10:53

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

dnolen15:10:07

they aren’t

dnolen15:10:13

it’s the deps file that makes everything work

dnolen15:10:14

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?

dnolen15:10:29

and add those to our generated deps file

juhoteperi15:10:53

Or maybe Closure already knows the requires etc. and we just need to ask for them when we get the processed source

juhoteperi15:10:17

CompilerInput has getRequires method

juhoteperi15:10:00

Not sure if that is correct for this case but I'll investigate and test

juhoteperi17:10:51

But for some reason I have problems using that

juhoteperi18:10:55

Oohh, the constructor is not public...

juhoteperi18:10:33

but compiler.parse might already run this pass

thheller18:10:33

Don’t you have all the necessary dependency infos from the module-deps script?

juhoteperi18:10:12

Probably, but the names would need to converted to the format closure uses module$absolute$file$path or such

thheller18:10:48

(ModuleNames/fileToModuleName js-require)

thheller18:10:00

(:import (com.google.javascript.jscomp.deps ModuleNames))

juhoteperi18:10:59

Hmm, there are cases where we don't use module-deps, like :es6/:common-js modules outside of node_modules

thheller18:10:16

ah ok, I’m not quite up to date how this all works in core

juhoteperi18:10:27

Ha, success, got input.getRequires working, needed to add this option to the compiler: (.setDependencyOptions (doto (DependencyOptions.) (.setDependencySorting true))))

juhoteperi19:10:41

Looks like ModuleNames/fileToModuleName is enough for convert-js-modules part, but analyzer breaks also

juhoteperi19:10:28

Due to missing symbol checks, :js-module-index etc. are correctly updated, but I think ::namespaces is not