Support Closure Compiler with --compilation_level=ADVANCED_OPTIMIZATIONS
See original GitHub issueIn Angular prior to version 10.0 it was possible to use Closure Compiler with --compilation_level=ADVANCED_OPTIMIZATIONS
flag, but the result of using Angular with these advanced optimizations were mixed.
In TypeScript 3.9 a change (microsoft/TypeScript#32011) was introduced that broke Closure Compiler support with this flag, and as a result of this we removed the remains of the Closure Compiler support from Angular via #37221.
This change affected only the ecosystem outside of Google, and had no effect on the usage of Angular with Closure Compiler inside of Google where we had more flexibility to work around the issue introduced by TypeScript 3.9. You can check out microsoft/TypeScript#38374 for one potential solution.
There is still a lot of value in bringing Closure Compiler support back to Angular in the non-Google ecosystem, but it’s unclear how much interest is there for this feature. We also don’t know, who if anyone, successfully used Closure Compiler with advanced optimizations and Angular outside of Google prior to Angular v10.0.
This issue is here to collect feedback from any existing developers that used Closure Compiler with Angular prior to Angular v10.0, as well as any developers not currently using Closure Compiler but interested in us supporting it.
If you are interesting in Angular supporting Closure Compiler with advanced optimizations, please share with us the following info via a comment on this issue:
- Do you have prior successful experience with using Closure Compiler and
--compilation_level=ADVANCED_OPTIMIZATIONS
? - Does this experience come from projects outside of Google’s internal monorepo?
- Why do you need this level of optimizations?
- Do you currently use Angular CLI?
- If you don’t use Angular CLI, what do you use to build your application?
- Do you use any other npm libraries that are compiled with your application and end up in your application build artifacts? Please list them. (e.g.
@angular/material
,@ng-bootstrap/ng-bootstrap
,@ngrx/*
, etc) - What is our bundle size? (in KB before compression)
- Do you use lazy loading / code splitting in your application?
- What version of Angular you are currently on?
- Any other input for us to consider?
Issue Analytics
- State:
- Created 3 years ago
- Reactions:24
- Comments:10 (6 by maintainers)
Top GitHub Comments
@DavidANeil thanks for the info! this is awesome! I’m quite confident that we’ll find some solution for you as long as we work together on this and we understand your requirements and constraints.
Angular must remain Closure compatible at its core because that’s how it’s used at Google. However I think that the npm packages themselves should not optimize for Closure consumption because 99.999% of our users don’t use Closure Compiler.
Besides consuming Angular from sources, another alternative is for us to deploy closure compatible packages into a private npm repo, or a git repo, similar how we already deploy pre-release build snapshots at https://github.com/angular/core-builds.
I see that we have a meeting scheduled for next week, so let’s chat about all the options. In the meantime, you might want to weigh in on ~microsoft/TypeScript#32011~ microsoft/TypeScript#38374 to let the TS team know that the TS 3.9 emit change affects people outside of Google as well.
I was actually investigating using Closure’s advanced optimizations for all the projects in our fairly large Angular codebase prior to upgrading to Angular 10. So was sad to see the support dropped, but understand it comes from TypeScript. Would love to see support again to continue on with our investigation! 🙂
Only in the experimental phase with one application. We never shipped this.
Yes
Some of our applications are compute intensive & we do end up fighting first party code size. So we are looking for joint ways to improve overall efficiency and size, web workers and Closure compiler being some.
Yes
4 300 KB - 8 000 KB uncompressed (range between our different applications).
Yes
10