-
Notifications
You must be signed in to change notification settings - Fork 25.3k
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
Comments
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.
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.
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.
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
Public record for Lucidchart:
Yes, for approximately 10 years.
Yes.
Because our application is, simply put, massive.
No.
Bazel,
Yes.
With advanced optimizations before compression: 21242KB (10105KB in the largest chunk)
Yes, we use closure chunks to lazily load a significant portion of our code.
9.1.1 with the Ivy renderer/compiler enabled.
We do not currently build Angular from source, but that is something we have been discussing doing recently. |
@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 |
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.
No, I never use before but really curious and want to try out.
N.A.
I've read that Closure Compiler can make the bundle size of applications even smaller than the combo of
Yes.
N.A.
Yes.
The total size of
Yes, the apps at my work follows closely Angular best practices regarding to lazy loading/code splitting
9.1.8 with the Ivy renderer/compiler enabled.
N.A. |
I opened a request for support of Closure Compiler back in 2016 We would love to use it for https://www.mustakbil.com
No
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 .
Yes
I can add you to a git repository, if you need.
Yes, both router based and component based.
10.0.0-next.6
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 :) |
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. |
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. |
+1 |
…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
@IgorMinar Is there documentation on how to now use Angular with advanced optimizations? |
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 |
This issue has been automatically locked due to inactivity. Read more about our automatic conversation locking policy. This action has been performed automatically by a bot. |
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:
--compilation_level=ADVANCED_OPTIMIZATIONS
?@angular/material
,@ng-bootstrap/ng-bootstrap
,@ngrx/*
, etc)The text was updated successfully, but these errors were encountered: