Making DepsGenerator work/useful

[Nate]

Hi All!

Long time.

I'd like to use closure compiler (along with the internal parser/ast) to do deps.js calculation. At this point, I find it redundant to use any of the many other tools for this (eg calcdeps[1], closurebuilder/depswriter[2], closure-deps[3]).

I noticed in the code there's DepsGenerator.java[4] but I can't find an obvious way to run it out of the box.

In the DepsGenerator tests[5] I noticed a list of SourceFile needs to be passed... 

I'd like to have this functionality part of the command line compiler, so that as soon as one selects files/entrypoints/etc for compilation, those sourcefiles will get passed to the DepsGenerator to generate a deps.js which is written to an output file specified by some command line argument.

Haven't been in the source tree for many years. I figure either post parsing/compilation would be the best moment for this pass to run. The most pruned result given a set of inputs would be ideal. There's a Compiler.getResult() [6] function which has a Set of transpiled Files. Trying to find the right point to slot it in... end of AbstractCommandLineRunner.doRun()[7]?

Any thoughts about implementation/otherwise?

Thank You!

Nate

[1] https://github.com/google/closure-library/blob/888396f117c33eb02e560829a53305e8ce3e5ba4/closure/bin/calcdeps.py

[2] https://github.com/google/closure-library/tree/888396f117c33eb02e560829a53305e8ce3e5ba4/closure/bin/build

[3] https://github.com/google/closure-library/tree/888396f117c33eb02e560829a53305e8ce3e5ba4/closure-deps

[4] https://github.com/google/closure-compiler/blob/888396f117c33eb02e560829a53305e8ce3e5ba4/src/com/google/javascript/jscomp/deps/DepsGenerator.java

[5] https://github.com/google/closure-compiler/blob/888396f117c33eb02e560829a53305e8ce3e5ba4/test/com/google/javascript/jscomp/deps/DepsGeneratorTest.java

[6] https://github.com/google/closure-compiler/blob/888396f117c33eb02e560829a53305e8ce3e5ba4/src/com/google/javascript/jscomp/Compiler.java

[7] https://github.com/google/closure-compiler/blob/888396f117c33eb02e560829a53305e8ce3e5ba4/src/com/google/javascript/jscomp/AbstractCommandLineRunner.java

[John Lenz]

I'm curious as to what aspect of the deps files you are using?  Internally to Google we have mostly moved away from deps.js files (we use bundles and collect dependency information for build tooling in other ways).

--

---
You received this message because you are subscribed to the Google Groups "Closure Compiler Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to closure-compiler-d...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/closure-compiler-discuss/1bac701d-304c-4b08-817d-5bf993621254n%40googlegroups.com.

[Nate]

Hey John!

If Google had any golden jewel, for the good of man, it was Closure project and especially the compiler. Thank you for your work.

We have a lot of legacy code still using the require/provide pattern. New and old projects are moving forward. Though, I'm still fond of the classic process; it was very productive. 

We develop in modern browsers, but we'll still be targeting ES5 in many/most cases. I can't wait to see how await/etc is transpiled, and how well it all works.

I'll have to catch up on any code/module loading patterns. I asked about the module loader specs years ago, and I'm still aware of any concrete definition and wide implementation of all the things required to hook into the ES6 import process. I can't even find a reference to what I'm looking for.. I think it was System.register, "system module loader", or some such. As it stands, the file/module loading abstracted by closure (deps.js and base.js) is superior.

We certainly do employ similar build patterns... The deps.js generation was really only part of the development cycle when fully uncompiled.  We create a deps.js; include it and base.js in any given page, script, and we're in the race. We also used this for uncompiled test cases involving DOM/HTML. Again, super productive in many other cases. The details of getting interop with goog.require/provide/etc and ES6 are outlined in the closure library, so I'm basing from there. [1] 

Thank You!

Nate

[1] https://github.com/google/closure-library/wiki/ES6-modules-and-Closure-Library

[John Lenz]

RE: the ES system loader specs

The system loader is dead.  If you want to intercept you have to either do it ahead of time, like we handle transpilation in base.js, as part of a build, or using a service worker.  The service worker is limited because you can't change how names are resolved.

RE: deps.js

Sounds like you use it for the classical development workflow.  That's fine, I just wanted to understand the use case.

If you file a bug, I can talk to the team about making the deps/ package command-line public.  I don't think there will be much interest in exposing it on the compilers command line.   We are slowly shifting to  Typescript frontend and this would be a step in the wrong direction.

To view this discussion on the web visit https://groups.google.com/d/msgid/closure-compiler-discuss/8f37fc9d-a138-48dc-adc7-8c385cffe8can%40googlegroups.com.

[Nate]

Thank You. 

Case closed re system loader.

Modern web/Javascript development workflows are often a mess. I appreciate your understanding. 

Will file once I make a handle. 

I find the comment based typing of closure to be unique and superior to typescript in many ways. In major, it allows the language to stay static, when the syntax probably often should, and allows the typing expressions evolve in a separate space. It may not be as concise (where tooling fits in), but it worked really well.

Thanks again!