Closure Library and current j2cl-m-p setup

[treblereel]

Closure Library contains many nice goodies and widgets, so it ll be nice to have them. I have started jsinteropting closure-library files, but i have faced that right now it's not possible to run it with current j2cl-m-p setup.

The reason of it is [JSC_DUPLICATE_NAMESPACE] Duplicate namespace Exception, because this set of closure-library files is different if i run tests and watch mode.

I think, it can be solved by moving these files from closure-test to bootstrap, maybe except of goog/testing.

WDYT ?

[niloc132]

Presently, our maven distribution of j2cl includes some parts of closure-library and is heavily biased to just gathering the parts required for j2cl to work - wiring for longs, asserts, goog.base itself, some other jsinterop-base details I think too. At some point, this also included other basic wiring from within j2cl itself, but since then, that has moved to the JRE jszip, so the name of this as "bootstrap" and restricting it to only those few types may no longer make sense.

The second jszip that we provide is just the parts of closure-library missing from that other jszip so that tests can be run at all - again, a very minimal set.

Both of these are configurable - if you were to publish a new artifact you could specify it as <bootstrapJsZip>com.company:my-bootstrap:1.0.0</bootstrapJsZip>. This could in theory contain all of closure-library, then to make tests work you would only have to provide an empty jszip in turn to testJsZip. This is not a very serious suggestion, just how it would work today.

The first idea that comes to mind is to replace this with just a single configuration arg, something like closureJsZip, and offer a few defaults. For example, a minimal+test could be the default for all goals (or perhaps only the minimal one, and let j2cl:test replace this with minimal+test), and a full closure-library could also be built as part of the maven release of j2cl. Then, if you really want a different closure-library, or additional extra stuff to be included (without specifying it as a new scope=runtime dependency - note that to just add things, this is the better choice), you can use this to override the default value.

So, two questions to answer about handling this:

• Do we want to only offer a single configuration option for "the expected js to load in all apps, appsbesides the JRE"? In a way, I hate having this at all (it would make a better dependency that the app should provide), except that 95+% of all apps will want the default, and further will want it automatically managed on upgrades (if you update j2cl-m-p, you should expect j2cl, closure-compiler and closure-library all to update too). Note that we do (presently) allow replacing the jre.jar and jszip, as well as others, so this isn't a huge leap, but definitely should be considered an advanced feature. Just one config (or none at all) means we should do the combined jszip, so that use cases like yours can supported.
• Assuming one or none, should we plan on "minimal+test" or "all of closure-library", or offer both and default to "minimal+test"?

[treblereel]

@niloc132 thanks for your detailed explanation. From my point of view, we could just have jszip with minimal+tests for tests and build/watch modes. If anyone wants to have additional parts of closure library they can add missing files by themselves.

[niloc132]

Picking this up again, since it came up in gitter a few weeks ago, and i'm prepping for a 0.19 release to maven central. Closure-library removed the py script that I previously used to start from "entrypoints" and collect the files that were needed to make a closure-library build.

As far as I can tell there is no simple way without making an extra build file to request this info. Roughly you need to make a custom bazel rule to start from an entrypoint and collect the .js files that are required.

Additionally, there isn't a nice way to say "get all of the non-test files, so that we can just lazily pick up the ones we need". There are two reasons for this:

• First, we can't just zip up all .js files, since our closure-compiler args specify dependencyMode=SORT_ONLY so that entrypoints/"serviceloaders" work
• Any test files (they are not consistently named...) will end up getting consumed by this, and will try to run when any application is generated.

Either we have to find a better way to select just the files we want, or give up on SORT_ONLY (see #69 for the discussion on why we really want SORT_ONLY).

Selecting only the files we want seems like it should be easier than it is - the simplest answer right now is to make a bazel rule that specifies the modules you're interested in, and have it collect required dependencies. Producing the closure-test artifact partly follows this, with a healthy dose of trial and error to see what was missed.