Downlevel static properties initializer to be contained within the class IIFE to aid Uglify in dead code removal

[IgorMinar]

TypeScript currently down-levels classes with static property initializers being outside of the class IIFE when targeting ES5. This prevents Uglify 2.8+ from removing the class from the final application bundle (after the class IIFEs have been independently annotated with the /*#__PURE__*/ annotation (see #13721) and there are no other references to the class).

Changing the down-leveling to keep the assignment within the IIFE just as static methods are down-leveled would resolve this problem and make lots of code eligible for dead code elimination by uglify (after the IIFEs have been marked with the pure annotation).

The change should be backwards compatible unless the current down-leveling approach was intentional to deal with some unusual corner-case that I'm not aware of.

TypeScript Version: 2.2.1 / nightly (2.2.0-dev.201xxxxx)

Code

class MyHappyClass {
 static myStaticProp = 'this is a simple static prop';
 static myStaticMethod() { return 'static method' };
}

Expected behavior:

var MyHappyClass = (function () {
 function MyHappyClass() {
 }
 MyHappyClass.myStaticMethod = function () { return 'static method'; };
 MyHappyClass.myStaticProp = 'this is a simple static prop';
 return MyHappyClass;
}());

Actual behavior:

The code above downlevels to the static prop being initialized

var MyHappyClass = (function () {
 function MyHappyClass() {
 }
 MyHappyClass.myStaticMethod = function () { return 'static method'; };
 ;
 return MyHappyClass;
}());
MyHappyClass.myStaticProp = 'this is a simple static prop';

Playground link

[mhegazy]

Just to clarify, this is needed in conjunction with #13721. this change without #13721 is not sufficient, correct?

[IgorMinar]

Mohamed Hegazy (@mhegazy) not quite. I already have a tool that adds the pure annotations as requested in #13721. it's a bit hacky, but works. Correcting the static prop downleveling is much harder to do as a transform on the ES5 code, so I'd prefer it to be implemented in tsc rather than outside.

(just to clarify, even though I have a tool for #13721, I still think that having typescript emit this annotation is quite critical for all uglify users, which is most of the client-side web today, because one shouldn't need to resort to hacks in order to have code downleveled by typescript to be removed if not needed).

[mhegazy]

The emitted goes into phases, the first is to emit an ES6 class from a TS class, and then ES6 class to ES5 class. that is why you see the class written out in such way. doing it all in one closure is doable but will require some wrangling on our side and some hacks here and there to get it to work. not a simple change though.

[IgorMinar]

Mohamed Hegazy (@mhegazy) static props are quite common and large parts of Angular and Angular Material are currently retained because of this issue, so fixing it along with #13721 would have a huge impact on all client-side code transpiled by typescript.

[kzc]

This related Babel issue outlines a pure annotation plugin for down-levelled ES6 classes and a proof-of-concept hack for the static method IIFE problem.

[mhegazy]

Igor Minar (@IgorMinar), would not this be considered an uglify bug? you did tell uglify that this value should is sage to be removed using /*#__PURE__*/ , but yet it keeps it around just because of a write to it.

[kzc]

you did tell uglify that this value should is sage to be removed using /*#__PURE__*/, but yet it keeps it around just because of a write to it.

It's a write to a property, so it's trickier. Uglify does not perform SSA. Pull requests are welcome.

We're going for low hanging fruit here. It is much easier for the code generator to emit the static properties within an IIFE marked with a pure annotation comment out front.

[IgorMinar]

Mohamed Hegazy (@mhegazy) I agree with kzc, the effort on emitting this correctly is much lower than doing full static analysis, which you have done with info at much higher fidelity.

Uglify would also need to be sure that the assignment is not into a setter which could have non-local side-effect, and right there things get very complicated very quickly.

[kzc]

I don't know the Typescript code base but the proof-of-concept Babel hack to move static properties into the IIFE was a few lines.

[rbuckton]

Will this also be an issue if you try to use Uglify on ES6 output? For example:

// es6 output
class MyHappyClass {
 static myStaticMethod() { return 'static method'; };
}
MyHappyClass.myStaticProp = 'this is a simple static prop';

[kzc]

Ron Buckton (@rbuckton) I see what you're getting at - there's no way to set a static property within an ES2015 class definition. uglify-es does not drop the unused class if it has static property assignments.

This annotation proposal is for ES5 code generation only. Typescript ES6 code generation can remain the same.

The previously mentioned Babel hack relies on the static property proposal implemented in babel-plugin-transform-class-properties, which if I'm not mistaken is also valid typescript:

class C { 
 method() {}
 static static_method() {} 
 static static_prop = 1; 
}

--> babel + babel-plugin-transform-class-properties + hack -->

// ...polyfills...

var C = /*#__PURE__*/function () {
 function C() {
 _classCallCheck(this, C);
 }

 _createClass(C, [{
 key: "method",
 value: function method() {}
 }], [{
 key: "static_method",
 value: function static_method() {}
 }]);

 C.static_prop = 1;
 return C;
}();