Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support Closure Compiler with --compilation_level=ADVANCED_OPTIMIZATIONS #37234

Closed
IgorMinar opened this issue May 21, 2020 · 10 comments
Closed
Labels
area: packaging Issues related to Angular's creation of npm packages feature: under consideration Feature request for which voting has completed and the request is now under consideration feature Issue that requests a new feature
Milestone

Comments

@IgorMinar
Copy link
Contributor

IgorMinar commented May 21, 2020

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?
@IgorMinar IgorMinar added feature Issue that requests a new feature area: packaging Issues related to Angular's creation of npm packages labels May 21, 2020
@ngbot ngbot bot added this to the Backlog milestone May 21, 2020
IgorMinar added a commit to IgorMinar/angular that referenced this issue May 21, 2020
As of TypeScript 3.9, the tsc emit is not compatible with Closure
Compiler due to
microsoft/TypeScript#32011.

There is some hope that this will be fixed by a solution like the one
proposed in
microsoft/TypeScript#38374 but currently it's
unclear if / when that will
happen.

Since the Closure support has been somewhat already broken, and the
tsickle pass has been a source
of headaches for some time for Angular packages, we are removing it for
now while we rethink our
strategy to make Angular Closure compatible outside of Google.

This change has no affect on our Closure compatibility within Google
which work well because all the
code is compiled from sources and passed through tsickle.

This change only disables the tsickle pass but doesn't remove it.

A follow up PR should either remove all the traces of tscikle or
re-enable the fixed version.

BREAKING CHANGE: Angular npm packages no longer contain jsdoc comments
to support Closure Compiler's advanced optimizations

The support for Closure compiler in Angular packages has been
experimental and broken for quite some
time.

As of TS3.9 Closure is unusable with the JavaScript emit. Please follow
microsoft/TypeScript#38374 for more
information and updates.

If you used Closure compiler with Angular in the past, you will likely
be better off consuming
Angular packages built from sources directly rather than consuming the
version we publish on npm
which is primarily optimized for Webpack/Rollup + Terser build pipeline.

As a temporary workaround you might consider using your current build
pipeline with Closure flag
`--compilation_level=SIMPLE`. This flag will ensure that your build
pipeline produces buildable and
runnable artifacts, at the cost of increased payload size due to
advanced optimizations being disabled.

If you were affected by this change, please help us understand your
needs by leaving a comment on
angular#37234.
IgorMinar added a commit to IgorMinar/angular that referenced this issue May 21, 2020
As of TypeScript 3.9, the tsc emit is not compatible with Closure
Compiler due to
microsoft/TypeScript#32011.

There is some hope that this will be fixed by a solution like the one
proposed in
microsoft/TypeScript#38374 but currently it's
unclear if / when that will
happen.

Since the Closure support has been somewhat already broken, and the
tsickle pass has been a source
of headaches for some time for Angular packages, we are removing it for
now while we rethink our
strategy to make Angular Closure compatible outside of Google.

This change has no affect on our Closure compatibility within Google
which work well because all the
code is compiled from sources and passed through tsickle.

This change only disables the tsickle pass but doesn't remove it.

A follow up PR should either remove all the traces of tscikle or
re-enable the fixed version.

BREAKING CHANGE: Angular npm packages no longer contain jsdoc comments
to support Closure Compiler's advanced optimizations

The support for Closure compiler in Angular packages has been
experimental and broken for quite some
time.

As of TS3.9 Closure is unusable with the JavaScript emit. Please follow
microsoft/TypeScript#38374 for more
information and updates.

If you used Closure compiler with Angular in the past, you will likely
be better off consuming
Angular packages built from sources directly rather than consuming the
version we publish on npm
which is primarily optimized for Webpack/Rollup + Terser build pipeline.

As a temporary workaround you might consider using your current build
pipeline with Closure flag
`--compilation_level=SIMPLE`. This flag will ensure that your build
pipeline produces buildable and
runnable artifacts, at the cost of increased payload size due to
advanced optimizations being disabled.

If you were affected by this change, please help us understand your
needs by leaving a comment on angular#37234.
IgorMinar added a commit to IgorMinar/angular that referenced this issue May 21, 2020
As of TypeScript 3.9, the tsc emit is not compatible with Closure
Compiler due to
microsoft/TypeScript#32011.

There is some hope that this will be fixed by a solution like the one
proposed in
microsoft/TypeScript#38374 but currently it's
unclear if / when that will
happen.

Since the Closure support has been somewhat already broken, and the
tsickle pass has been a source
of headaches for some time for Angular packages, we are removing it for
now while we rethink our
strategy to make Angular Closure compatible outside of Google.

This change has no effect on our Closure compatibility within Google
which work well because all the
code is compiled from sources and passed through tsickle.

This change only disables the tsickle pass but doesn't remove it.

A follow up PR should either remove all the traces of tscikle or
re-enable the fixed version.

BREAKING CHANGE: Angular npm packages no longer contain jsdoc comments
to support Closure Compiler's advanced optimizations

The support for Closure compiler in Angular packages has been
experimental and broken for quite some
time.

As of TS3.9 Closure is unusable with the JavaScript emit. Please follow
microsoft/TypeScript#38374 for more
information and updates.

If you used Closure compiler with Angular in the past, you will likely
be better off consuming
Angular packages built from sources directly rather than consuming the
version we publish on npm
which is primarily optimized for Webpack/Rollup + Terser build pipeline.

As a temporary workaround you might consider using your current build
pipeline with Closure flag
`--compilation_level=SIMPLE`. This flag will ensure that your build
pipeline produces buildable and
runnable artifacts, at the cost of increased payload size due to
advanced optimizations being disabled.

If you were affected by this change, please help us understand your
needs by leaving a comment on angular#37234.
kara pushed a commit that referenced this issue May 21, 2020
As of TypeScript 3.9, the tsc emit is not compatible with Closure
Compiler due to
microsoft/TypeScript#32011.

There is some hope that this will be fixed by a solution like the one
proposed in
microsoft/TypeScript#38374 but currently it's
unclear if / when that will
happen.

Since the Closure support has been somewhat already broken, and the
tsickle pass has been a source
of headaches for some time for Angular packages, we are removing it for
now while we rethink our
strategy to make Angular Closure compatible outside of Google.

This change has no effect on our Closure compatibility within Google
which work well because all the
code is compiled from sources and passed through tsickle.

This change only disables the tsickle pass but doesn't remove it.

A follow up PR should either remove all the traces of tscikle or
re-enable the fixed version.

BREAKING CHANGE: Angular npm packages no longer contain jsdoc comments
to support Closure Compiler's advanced optimizations

The support for Closure compiler in Angular packages has been
experimental and broken for quite some
time.

As of TS3.9 Closure is unusable with the JavaScript emit. Please follow
microsoft/TypeScript#38374 for more
information and updates.

If you used Closure compiler with Angular in the past, you will likely
be better off consuming
Angular packages built from sources directly rather than consuming the
version we publish on npm
which is primarily optimized for Webpack/Rollup + Terser build pipeline.

As a temporary workaround you might consider using your current build
pipeline with Closure flag
`--compilation_level=SIMPLE`. This flag will ensure that your build
pipeline produces buildable and
runnable artifacts, at the cost of increased payload size due to
advanced optimizations being disabled.

If you were affected by this change, please help us understand your
needs by leaving a comment on #37234.

PR Close #37221
@DavidANeil
Copy link
Contributor

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
Copy link
Contributor Author

IgorMinar commented May 22, 2020

@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
Copy link
Contributor

ahnpnl commented May 24, 2020

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
Copy link
Contributor

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
Copy link

kemsky commented May 25, 2020

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
Copy link
Contributor

matthewjh commented May 28, 2020

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.

@craftmaster2190
Copy link

+1

profanis pushed a commit to profanis/angular that referenced this issue Sep 5, 2020
…37221)

As of TypeScript 3.9, the tsc emit is not compatible with Closure
Compiler due to
microsoft/TypeScript#32011.

There is some hope that this will be fixed by a solution like the one
proposed in
microsoft/TypeScript#38374 but currently it's
unclear if / when that will
happen.

Since the Closure support has been somewhat already broken, and the
tsickle pass has been a source
of headaches for some time for Angular packages, we are removing it for
now while we rethink our
strategy to make Angular Closure compatible outside of Google.

This change has no effect on our Closure compatibility within Google
which work well because all the
code is compiled from sources and passed through tsickle.

This change only disables the tsickle pass but doesn't remove it.

A follow up PR should either remove all the traces of tscikle or
re-enable the fixed version.

BREAKING CHANGE: Angular npm packages no longer contain jsdoc comments
to support Closure Compiler's advanced optimizations

The support for Closure compiler in Angular packages has been
experimental and broken for quite some
time.

As of TS3.9 Closure is unusable with the JavaScript emit. Please follow
microsoft/TypeScript#38374 for more
information and updates.

If you used Closure compiler with Angular in the past, you will likely
be better off consuming
Angular packages built from sources directly rather than consuming the
version we publish on npm
which is primarily optimized for Webpack/Rollup + Terser build pipeline.

As a temporary workaround you might consider using your current build
pipeline with Closure flag
`--compilation_level=SIMPLE`. This flag will ensure that your build
pipeline produces buildable and
runnable artifacts, at the cost of increased payload size due to
advanced optimizations being disabled.

If you were affected by this change, please help us understand your
needs by leaving a comment on angular#37234.

PR Close angular#37221
@DavidANeil
Copy link
Contributor

@IgorMinar Is there documentation on how to now use Angular with advanced optimizations?
The commit message describes building from source, but the test suite was disabled for advanced optimizations and so code is being merged that is not compatible.
ca11ef2#diff-5b216191e60f7d96c265becebdd0d1f11b3930a9135ca9be8b75b548071efad1R38 is an example of code that is not closure-compatible.

@dunxen
Copy link

dunxen commented Dec 23, 2020

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! 🙂

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

Only in the experimental phase with one application. We never shipped this.

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

Yes

  • Why do you need this level of optimizations?

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.

  • 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/material
  • What is our bundle size? (in KB before compression)

4 300 KB - 8 000 KB uncompressed (range between our different applications).

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

Yes

  • What version of Angular you are currently on?

10

@angular-robot angular-robot bot added the feature: under consideration Feature request for which voting has completed and the request is now under consideration label Nov 28, 2021
@alxhub alxhub closed this as completed Mar 28, 2022
@angular-automatic-lock-bot
Copy link

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

This action has been performed automatically by a bot.

@angular-automatic-lock-bot angular-automatic-lock-bot bot locked and limited conversation to collaborators Apr 28, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
area: packaging Issues related to Angular's creation of npm packages feature: under consideration Feature request for which voting has completed and the request is now under consideration feature Issue that requests a new feature
Projects
None yet
Development

No branches or pull requests

9 participants