Apparently we don't have a tracking bug for this, but GYP is about to be turned off and we need to figure out how to migrate the Closure Compilation builders to GN as soon as possible ...
... or, they can just break when people decide to delete the compiled_resources.gyp files because they don't want to have to list these files in two different build systems.
Chromecast has some internal .js files that we used to compile with the third_party/closure_compiler/compile_js.gypi target.
This was primarily used for error checking, since we didn't actually ship the compiled versions.
But there seems to be no GN equivalent for that target yet, so we are missing that functionality (which was very helpful for catching a variety of bugs).
It was useful enough the developers still keep an old checkout around so they could run the gyp rule to compile the js files with all depends and externs and such properly.
Oops, sorry, I was unclear. Chromecast doesn't support GYP internally anymore; we got rid of all our gyp files and nobody builds anything with gyp. So devs would keep an old Chromecast project checkout, which still has the gyp files + support in it in order to do the compile via the compile_js.gypi helper.
We have a rule now that does something similar to //ios/web/js_compile:js_compile_checked template (but with the bundling part); so we can compile/check files individually.
We just don't get the depends functionality that the compile_js.gypi gives, which I think is needed to properly do a lot of the type checking if files are referencing each other?
Update: we still need to do this, and I still haven't gotten to it. I'm downgrading this to P2, but that doesn't mean I think it's actually any less important, rather that I just set the priority wrong initially and that I have other things that I need to prioritize higher.
If someone else wants to claim this, that's certainly fine by me :).
I've looked at this a bit, js_library doesn't compile every single node in the dependency tree independently like the current gyp system does. I'm not even sure if this is something that we want to keep.
e.g We have app.js that depends on sidebar.js, we'll compile sidebar.js by itself, then app.js with sidebar.js.
This ensures that each library's dependencies are correctly listed, but I'm not sure if this is worth the n^2 behavior of the Closure build.
Any thoughts?
I agree that the n^2 behavior is not desired. I have documented this in an upcoming document about various WebUI issues that I consider important to fix in the near future.
I understand the minor side-benefit of ensuring that each library has the correct dependencies listed, but I don't think this is as important, especially with the coming of ES6 modules (already enabled by default on M61).
For example the TypeScript compiler will complain when a file is using a module that has not directly imported, even if a single invocation of TSC is occurring AND some other file is transitively importing the missing module. Hoping that the JSC will have same behavior with ES6 modules, although I have not tested this.
I recently attempted to use closure compilation and was confused on why it was not working. I finally realized the problem was that I was building for Android; switching to Linux solved it. Would it be possible to allow closure compilation to run on all/most target platforms?
Let me know if I should file a new issue for this.
#49: In general the compilation should work wherever the WebUI exists. However, some conditions may not be correct, so do feel free to change the compile platforms of WebUIs if they're wrong. Thanks!
Should authors of pending CLs that already have the following line in their CL description
Cq-Include-Trybots: luci.chromium.try:closure_compilation
manually update their CLs? It would be nice to send a PSA if that's the case.
Comment 1 by dpranke@chromium.org
, Jul 28 2016