Emit /*@__PURE__*/ before class declaration

[IgorMinar]

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: mishoo/UglifyJS@1e51586
• TypeScript issue Pure annotation in downlevel emits microsoft/TypeScript#13721

[mprobst]

Do we recommend people to use uglify for dead code elimination? I thought we'd rely on webpack for that?

[alexeagle]

Answering Igor's question from another thread: technically speaking, this would be very easy to do.

[IgorMinar]

@mprobst webpack doesn't eliminate anything that is reachable from the entry point via ES imports. It relies on Uglify to remove the module bodies and minify the code. Uglify however can't safely determine if a class downleveled to an IIFE is safe to remove, so it retains them all.

@alexeagle I'm at the point in my research where this issue is overshadowing all the other issues and I can't make progress until this issue is fixed. Would you or someone else from the tooling team be able to implement this on a branch so that I can't test it and verify that the impact is as big as it seems?

[evmar]

I imagine you can use a sed script to get most of this for experimentation purposes.

Unfortunately it's a bit hard to hack this into tsickle. We either see the code before downlevelling (in which case it's a "class" keyword and there's no place to put the comment) or after downlevelling (in which case it's a soup of function calls and we don't know which ones are classes anymore). Hooking into the TS transformation pipeline would probably allow this kind of change but that's a new API that we don't use yet.

[IgorMinar]

@evmar this is exactly what I was afraid of :-(

[IgorMinar]

@evmar sed is kind of impractical, but I can try it. I wonder if forking typescript and experimenting with a fork would be better/faster way to get some reliable results that would allow me to estimate the impact of this change.

[evmar]

TS is now a series of transformations. Here's the place where "class" is transformed into the function:
https://github.com/Microsoft/TypeScript/blob/c949116fa92a0f7d4683f8f698be47bf1b15eb92/src/compiler/transformers/es2015.ts#L661

However, I don't know how to adjust that to insert a comment. I think @rkirov has played with this API and would know.

[IgorMinar]

This would however mean that we'd need our toolchain updated to TypeScript HEAD/2.3, which is not an easy feat.

[evmar]

Yeah. I think for experimentation purposes you can check out an old version of TS and hack in the change locally. I'm not sure if that's easier than doing something with sed.

I think the fastest thing you can do is something like

grep -r '^class ' * > list_of_classes.py

followed by hacking up that output into a that finds those specific "var ..." lines and inserts your annotation.

[alexeagle]

Even with TS 2.3 you can only add transforms at the beginning or the end, so it's the same power tsickle has now (just a more composable and performant implementation)
I'm working on that upgrade now because I need it for TypeScript in Bazel. (But we won't land it until TS 2.3 is released).

I see you're saying that
https://www.typescriptlang.org/play/#src=%2F*%40__PURE__*%2F%0D%0Aclass%20Foo%20%7B%7D%0D%0A
puts the comment in the wrong place, it's before the var but for rollup it needs to be on the RHS of the assignment? I imagine tsickle could re-write the comment to move it after TS downlevels.

[IgorMinar]

to my big surprise I found the following JS regexp replacement working quite well:

function(fileBody) {
    return fileBody
      .replace(
          /^(var (\S+) = )(\(function \(\) \{\n(?:    (?:\/\*\*| \*|\*\/|\/\/)[^\n]*\n)*    function \2\([^\)]*\) \{\n)/mg,
          '$1/*@__PURE__*/$3'
      )
      .replace(
          /^(var (\S+) = )(\(function \(_super\) \{\n    __extends\(\2, _super\);\n)/mg,
          '$1/*@__PURE__*/$3'
      );
};

[evmar]

I like it!

[IgorMinar]

I dumped my hacky tool on github as a gist in case anyone wants to play with this before it's properly implemented either in typescript or in tsickle: https://gist.github.com/IgorMinar/09eadcb221a8253162078210639a344d

[IgorMinar]

Oh, and btw the size gains are totally worth the effort of rolling this out properly.