Emit /*@__PURE__*/ before class declaration

Based on this research, I believe that if we were able to emit a newly supported /*@__PURE__*/ annotation in front of class declaration and ensure that it gets preserved in the final down-leveled output, @angular/cli and any other Uglify-based build tool chains would be able to use dead-code elimination tricks to remove all unused classes (pipes, directives and components) with the exception of unused services.

There is a feature request Microsoft/TypeScript#13721 to add this functionality to tsc, but it’s unclear when/if it’s going to be implemented, so I wonder how easy it would be to implement this kind of feature in tsickle so that we can experiment.

What I’d like is given the following input:

export class SomeClass {}

I’d like tsc + tscikle to output downleveled es5 code that looks like this:

var SomeClass = /*@__PURE__*/(function () {
  function SomeClass() {}
  return SomeClass;
}());

If for some reason we have a concern that /*@__PURE__*/ could cause headaches for Closure, we can also use /*#__PURE__*/, which is equally supported by Uglify.

More info:

• research doc: https://goo.gl/ZVdWlt
• Uglify’s commit introducing inline annotations for pure functions: https://github.com/mishoo/UglifyJS2/commit/1e51586996ae4fdac68a8ea597c20ab170809c43
• TypeScript issue Microsoft/TypeScript#13721

[IgorMinar]

It depends on the app but basically all classes down leveled by tsc are retained by uglify without this fix. Our code is mostly classes, so is rxjs and material. So you can do the math. We are talking double digits. 60-70% in some cases.

On Thu, Mar 30, 2017, 10:01 AM Martin Probst [e-mail] wrote:

Igor: just out of curiosity, what are the size gains like?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/angular/tsickle/issues/452#issuecomment-290475081, or mute the thread https://github.com/notifications/unsubscribe-auth/AANM6NFyxOxTeyH3jd-Do45uY0E4rjNWks5rq9_WgaJpZM4Mp04Q .

[IgorMinar]

I’m going to close this issue, because if we were to implement this in tsickle, we’d be missing out on annotating anything that comes into the app from node_modules that has not been processed by tsickle. Instead we are either going to rely on tsc to do this (Microsoft/TypeScript#13721 ), or in the short term we’ll have our own tool integrated into the angular-cli that would prefix all the ts and js code that makes up an application be annotated in this way.