Wrap classes with decorators or static properties in an IIFE, even for ES2015+ #32011

clydin · 2019-06-20T21:13:20Z

Currently only script targets less than or equal to ES5 will wrap classes with decorators and/or static properties. However, the wrapping is also crucial to file size optimizations for ES2015+ as well. Without the IIFE wrapper, minification tools do not elide the class. This is due to references to the class being present within the downlevelled decorator and static property code.
This change represents the full completion of issue #15857

sandersn

@clydin Can you open a separate issue to explain how this fixes #15857? It was already fixed by #16120 when you opened this, so I think that it must be an extension of that somehow.

@rbuckton you might want to take a look now and see how this relates to #16120.

clydin · 2020-02-03T18:53:08Z

@sandersn Issue #15857 was only partially fixed by #16120. That PR only fixed the issue when the tsconfig target was ES5. It did not fix the issue when the target was ES2015 or higher.
This was not so much of a problem at the time since targeting ES2015+ was uncommon. However, now that ES2015 browser support is commonplace, targeting such versions is now the default in many cases.

rbuckton · 2020-02-04T23:20:54Z

For ES5, we were asked to mark the IIFE with a /** @class */ leading comment for some minifiers. Should we do this here too?

TypeScript/src/compiler/transformers/es2015.ts

Line 790 in 2e97918

    
           addSyntheticLeadingComment(result, SyntaxKind.MultiLineCommentTrivia, "* @class ");

clydin · 2020-02-05T16:14:12Z

Good question. I think that makes sense considering that the IIFE represents the totality of the Typescript class definition.

Currently only script targets less than or equal to ES5 will wrap classes. However, the wrapping is also crucial to file size optimizations for ES2015+ as well. Without the IIFE wrapper, minification tools do not elide the class. This is due to references to the class being present within the downlevelled decorator and static property code. This change represents the full completion of issue microsoft#15857

clydin · 2020-02-11T15:11:47Z

Updated to add the @class comment.

With this change we "vendor" TypeScript 3.6 in build optimizer instead of using directly the npm package. Reasons: - We cannot update to a more recent version of TypeScript due to microsoft/TypeScript#38412 - Yarn workspace are not supported under Bazel. This means currently we are running unit testswhich uses a different TypeScript version at runtime. - In TypeScript 3.9, the shape of ES2015 classes changed microsoft/TypeScript#32011, this requires some changes in the UT expects, but this again will not be correct to change now.

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 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 are rethinking our strategy to make thAngular 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.

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 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 are rethinking our strategy to make thAngular 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 reenable the fixed version. BREAKING CHANGE: Angular npm packages no longer contain jsdoc comments to support optimization by Closure Compiler The support for Closure compiler in Angular packages has been broken for quite some time. As of TS3.9 Closure is unusable with the JavaScript emit. Please follow microsoft/TypeScript#38374 for further developments. 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 vesion we publish on npm which is primarily optimized for Webpack/Rollup + Terser build pipeline.

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.

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

… even for ES2015+ (#32011)" This reverts commit 7cc4a8d.

* upstream/master: LEGO: check in for master to temporary branch. LEGO: check in for master to temporary branch. Fix relation between generic mapped types and types with index signatures (microsoft#38761) LEGO: check in for master to temporary branch. LEGO: check in for master to temporary branch. LEGO: check in for master to temporary branch. Revert "Wrap classes with decorators or static properties in an IIFE, even for ES2015+ (microsoft#32011)" Preserve module marker in es2015+ module emit for tool compatability (microsoft#38712) Fix recently added test so it is cross-plat fix(33286): add outlining for arrow function with one parameter (microsoft#38631) fix(38463): show completions for index access properties

…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

DanielRosenwasser assigned rbuckton Jul 30, 2019

DanielRosenwasser added this to the TypeScript 3.6.1 milestone Jul 30, 2019

clydin force-pushed the wrap-es2015 branch 3 times, most recently from 52eb471 to 7b5cbf6 Compare August 29, 2019 15:23

RyanCavanaugh modified the milestones: TypeScript 3.6.1, TypeScript 3.7.0, TypeScript 3.7.1 Sep 25, 2019

sandersn added this to Limbo in Pall Mall Jan 30, 2020

sandersn requested changes Feb 3, 2020

View reviewed changes

sandersn added this to Review in progress in PR Backlog Feb 3, 2020

sandersn removed this from Limbo in Pall Mall Feb 3, 2020

sandersn changed the title ~~Always wrap classes with decorators or static properties in an IIFE~~ Wrap classes with decorators or static properties in an IIFE, even for ES2015+ Feb 3, 2020

sandersn moved this from Waiting on author to Needs review in PR Backlog Feb 3, 2020

clydin added 2 commits February 6, 2020 10:59

Accept new baselines

9ff43af

clydin force-pushed the wrap-es2015 branch from 7b5cbf6 to 9ff43af Compare February 11, 2020 01:43

rbuckton approved these changes Feb 15, 2020

View reviewed changes

PR Backlog automation moved this from Needs review to Needs merge Feb 15, 2020

sandersn approved these changes Feb 15, 2020

View reviewed changes

sandersn merged commit 7cc4a8d into microsoft:master Feb 15, 2020

PR Backlog automation moved this from Needs merge to Done Feb 15, 2020

clydin deleted the wrap-es2015 branch February 15, 2020 00:37

weswigham mentioned this pull request Feb 20, 2020

use const instead of let for new class iife assignments #36907

Merged

rrdelaney mentioned this pull request May 6, 2020

Introduce new flag for minifier optimization hints #38374

Open

5 tasks

robpalme mentioned this pull request May 13, 2020

Static field emit is IIFE #38528

Closed

rrdelaney mentioned this pull request May 15, 2020

Introduces new flag for optimization hints #38602

Closed

IgorMinar mentioned this pull request May 20, 2020

Disable the tsickle pass from ng_package/APF/ngc-wrapped angular/angular#37221

Closed

IgorMinar mentioned this pull request May 21, 2020

Support Closure Compiler with --compilation_level=ADVANCED_OPTIMIZATIONS angular/angular#37234

Closed

DanielRosenwasser mentioned this pull request May 21, 2020

Design Meeting Notes, 5/21/2020 #38713

Closed

sandersn added a commit that referenced this pull request May 21, 2020

Revert "Wrap classes with decorators or static properties in an IIFE,…

79f1ec3

… even for ES2015+ (#32011)" This reverts commit 7cc4a8d.

sandersn mentioned this pull request May 21, 2020

Revert "Wrap classes with decorators or static properties in an IIFE,… #38719

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Wrap classes with decorators or static properties in an IIFE, even for ES2015+ #32011

Wrap classes with decorators or static properties in an IIFE, even for ES2015+ #32011

clydin commented Jun 20, 2019 •

edited

Loading

sandersn left a comment

clydin commented Feb 3, 2020 •

edited

Loading

rbuckton commented Feb 4, 2020

clydin commented Feb 5, 2020

clydin commented Feb 11, 2020

Wrap classes with decorators or static properties in an IIFE, even for ES2015+ #32011

Wrap classes with decorators or static properties in an IIFE, even for ES2015+ #32011

Conversation

clydin commented Jun 20, 2019 • edited Loading

sandersn left a comment

Choose a reason for hiding this comment

clydin commented Feb 3, 2020 • edited Loading

rbuckton commented Feb 4, 2020

clydin commented Feb 5, 2020

clydin commented Feb 11, 2020

clydin commented Jun 20, 2019 •

edited

Loading

clydin commented Feb 3, 2020 •

edited

Loading