Support Closure Compiler with --compilation_level=ADVANCED_OPTIMIZATIONS

[IgorMinar]

In 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?

[DavidANeil]

Public record for Lucidchart:

Do you have prior successful experience with using Closure Compiler and --compilation_level=ADVANCED_OPTIMIZATIONS?

Yes, for approximately 10 years.

Does this experience come from projects outside of Google's internal monorepo?

Yes.

Why do you need this level of optimizations?

Because our application is, simply put, massive.

Do you currently use Angular CLI?

No.

If you don't use Angular CLI, what do you use to build your application?

Bazel, @angular/bazel, rules_typescript, rules_nodejs, some custom rules for the closure compiler.

Do you use any other npm libraries that are compiled with your application and end up in your application build artifacts?

Yes. ngx-monaco-editor and tslib.

What is your bundle size? (in KB before compression)

With advanced optimizations before compression: 21242KB (10105KB in the largest chunk)

Do you use lazy loading / code splitting in your application?

Yes, we use closure chunks to lazily load a significant portion of our code.

What version of Angular are you currently on?

9.1.1 with the Ivy renderer/compiler enabled.

Any other input for us to consider?

We do not currently build Angular from source, but that is something we have been discussing doing recently.
We also have some minor patches to get everything working.
#36652 is one of them.
The other is to allow us to use the UnifiedModulesHost (which is normally only enabled for Blaze, and not Bazel).

[IgorMinar]

@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.

[ahnpnl]

Hi I was looking into documentations only to use Closure Compiler for projects at my work but unfortunately I don't find many resources or examples. I'm really interested in the support from Angular.

Do you have prior successful experience with using Closure Compiler and --compilation_level=ADVANCED_OPTIMIZATIONS?

No, I never use before but really curious and want to try out.

Does this experience come from projects outside of Google's internal monorepo?

N.A.

Why do you need this level of optimizations?

I've read that Closure Compiler can make the bundle size of applications even smaller than the combo of terser + webpack. I think this will greatly improve user experiences because the app can load faster.

Do you currently use Angular CLI?

Yes.

If you don't use Angular CLI, what do you use to build your application?

N.A.

Do you use any other npm libraries that are compiled with your application and end up in your application build artifacts?

Yes. ngx-monaco-editor, @ngxs/store, @ngneat/transloco, comlink, workbox, @angular/material, @angular/cdk, lodash-es, tslib.

What is your bundle size? (in KB before compression)

The total size of dist folder is: 21311.105KB (1597.766 KB in the largest chunk)

Do you use lazy loading / code splitting in your application?

Yes, the apps at my work follows closely Angular best practices regarding to lazy loading/code splitting

What version of Angular are you currently on?

9.1.8 with the Ivy renderer/compiler enabled.

Any other input for us to consider?

N.A.

[naveedahmed1]

I opened a request for support of Closure Compiler back in 2016
angular/angular-cli#2981 (and few others) but never new that its support was ever added to Angular CLI.

We would love to use it for https://www.mustakbil.com

Do you have prior successful experience with using Closure Compiler and --compilation_level=ADVANCED_OPTIMIZATIONS?

No

Why do you need this level of optimizations?

Angular CLI does an excellent job in generating production grade bundles, but I believe there's still some room of improvements to avoid issues like https://github.com/angular/angular-cli/issues/16866 .

Do you currently use Angular CLI?

Yes

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)

@angular/cdk
@angular/material
@angular/google-maps
@angular/fire
@angular/pwa
@nguniversal/module-map-ngfactory-loader
@ngx-lite/json-ld
@ngx-pwa/local-storage
@swimlane/ngx-charts
@trademe/ng-defer-load
aspnet-prerendering (for Server side rendering)
d3-shape
dayjs
file-saver
firebase
ng2-adsense
ng2-ckeditor
ngx-img-cropper
ngx-infinite-scroll
screenfull

I can add you to a git repository, if you need.

What is our bundle size? (in KB before compression)

main-es5 		1.34Mb
main-es2015		1.18Mb

Total es2015 bundles size			4.6Mb
Total es5 bundles size				4.97Mb


SSR bundle		4.68Mb

Do you use lazy loading / code splitting in your application?

Yes, both router based and component based.

What version of Angular you are currently on?

10.0.0-next.6

Any other input for us to consider?

Angular CLI does a great job in hiding all the complexities of the compilation, bundling and optimizations. It would be great to have same level simplicity to enable closure compiler and --compilation_level=ADVANCED_OPTIMIZATIONS.

I wish the Angular team the best of luck and look forward to the support of Closure compiler in Angular CLI :)

[kemsky]

We used Closure for a while because it supports multi-threading and our CI server has multiple slow cores. We use multiple 3rd party libraries which makes it difficult to use ADVANCED_OPTIMIZATIONS and as a result bundle size was too large. Then we switched to rollup and now we are back on angular-cli.

[matthewjh]

Do you have prior successful experience with using Closure Compiler and --compilation_level=ADVANCED_OPTIMIZATIONS?

No

Does this experience come from projects outside of Google's internal monorepo?

Why do you need this level of optimizations?

At Tradeweb we build a large, market-leading trading platform UI with Angular. It is a complex set of apps that use many libraries, both in-house and third-party, all set in a monorepo. Performance, both in terms of memory and CPU, and load time are critical (particularly as we have a lot of windows, some of them small and needing to be lightweight). It's clear that GCC goes very very far beyond other tools in the ecosystem in terms of static analysis and using static analysis to perform meaningful optimisations (for ex. dropping unused object properties and methods, inlining).

Do you currently use Angular CLI?

Yes

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)

@angular/material, @angular/cdk, ag-grid

What is our bundle size? (in KB before compression)

I'm not sure off the top of my head

Do you use lazy loading / code splitting in your application?

Yes, as much as we can

What version of Angular you are currently on?

10

Any other input for us to consider?

I think GCC is very important for Angular as a framework and that advanced optimisation tools like GCC (not that I really know of any others), and making them reasonable to use, are critical for keeping the future of HTML5 web apps -- and the internet -- fast. My worry is that in 5 years we'll be stuck with more or less the same tools with the same quite basic capabilities as terser/uglify.