Annotating transformed classes with #__PURE__ comment

[Andarist]

Q	A
Fixed Issues	fixes #5632
Patch: Bug Fix?	no
Major: Breaking Change?	no
Minor: New Feature?	yes
Tests Added/Pass?	yes
Spec Compliancy?
License	MIT
Doc PR	no
Any Dependency Changes?	no

This is a simple change which annotate created by transform-es2015-classes IIFEs with #__PURE__ comments. This allows UglifyJS to remove those IIFE calls if their result is unused - generally speaking it allows for better Dead Code Elimination.

The core of the change is here. The rest are only adjusted tests.

[babel-bot]

Build successful! You can test your changes in the REPL here: https://babeljs.io/repl/build/4825/

[nicolo-ribaudo]

Does UglifyJS remove this?

var A = /*#__PURE__*/ /* foo */ function() { /* ... */ }(X);

Which is the output for

var A = /* foo */ class A extends X {}

[nicolo-ribaudo]

Also, maybe this should be enabled using an option since not everyone uses UglifyJS after Babel?

[Andarist]

Does UglifyJS remove this?
var A = /#PURE/ /* foo / function() { / ... */ }(X);

Unfortunately not. They explicitly check only the last comment. I might poke around in the UglifyJS repo as well to make this work, or at least investigate why it doesnt.

Which is the output for
var A = /* foo */ class A extends X {}

Should be easy to add #__PURE__ as the last leading comment instead of putting it as first one. Ofc some other plugin could mess this up again. So the true solution is to work this out in UglifyJS itself. However this is quite an edge case (I dont believe many people use comments like this, also not that many plugins annotating functions like this) and I believe this could stay unchanged.

Also, maybe this should be enabled using an option since not everyone uses UglifyJS after Babel?

Ive also thought about this, however:

• I believe its better to have opt-out option. The biggest concern for me is that most people are not fully aware of the tools they use and how they work and I believe its better to add such comments by default and provide an option to disable this if somebody doesnt want it. Usage of UglifyJS is so vast in the community that it sounds reasonable to me to emit those annotations by default.
• I hadnt time to investigate how passing through options from the presets to the plugins should be done ;)

[hzoo]

It's fine as a default since it's a comment anyway, I was just confused as to what the comment is supposed to be? I thought it was @class before too @kzc

[hzoo]

good, pending review by @kzc or someone on uglify

also cc @boopathi

[kzc]

This is not important... but is there a reason why this is on 3 lines instead of 1?

[Andarist]

its just how babel-generator spits out code from the AST, looks weird to me too, but 🙄

[hzoo]

It's probably just because we removed some logic with newlines using tokens/comments so it's like that now

[kzc]

Seems fine. I assume @Andarist verified the result against uglify.

Will non-standard static class properties be generated within the IIFE as per #5632 (comment)?

[xtuc]

Lgtm 👍

[xtuc]

We could use this across multiple plugins? We might want to add it in a helper.

[Andarist]

@xtuc sure thing, whats the best place to add such?

[xtuc]

Too late but I had something like babel-help-emit-pure-annotation in mind but I'm not sure it will be used apart from here.

[hzoo]

I would just make it when we need/get to it. It's not a breaking change to swap it out either

[Andarist]

Will non-standard static class properties be generated within the IIFE as per #5632 (comment)?

I plan to work on it too, need to establish how it should be done though. The problem I see is that those 2 plugins are independent but they need to work together here somehow. Ideally also we could have 2 different outputs for:

• transpiled classes - just pull statics into the closure
• only transpiled statics - wrap class + statics into the closure

[Andarist]

It's fine as a default since it's a comment anyway, I was just confused as to what the comment is supposed to be? I thought it was @class before too @kzc

It seems that @class is emitted by the TS compiler and they refuse to use the #__PURE__ comment which is understandable by the UglifyJS - they propose that people use replacement plugins from @class to #__PURE__ comments i.e. with webpack plugin.

[kzc]

Will non-standard static class properties be generated within the IIFE as per #5632 (comment) ?

The problem I see is that those 2 plugins are independent but they need to work together here somehow.

I ran into the same issue when hacking together the proof of concept. I did not know how Babel plugins are supposed to communicate/coordinate with each other - via Babylon AST only?

Maybe just eliminate babel-plugin-transform-class-properties altogether and roll that functionality into some future version of babel-plugin-transform-es201X-classes?

[carrickjason]

Will non-standard static class properties be generated within the IIFE as per #5632 (comment)?

I plan to work on it too, need to establish how it should be done though. The problem I see is that those 2 plugins are independent but they need to work together here somehow. Ideally also we could have 2 different outputs for:

• transpiled classes - just pull statics into the closure
• only transpiled statics - wrap class + statics into the closure

@Andarist Do you know if this got solved anywhere? I'm still seeing class properties outside of the IIFE which is breaking treeshaking.

[Andarist]

You could try this https://github.com/emotion-js/emotion/blob/64a39f1eb6abf5afe6949b702436423938f34fd0/scripts/build/fix-dce-for-classes-with-statics.js , just keep in mind that this might break your code - it's not overly tested 😉

I unfortunately couldn't find time yet to revive my old PR to fix this issue, I was hoping that this PR would get merged in #8130 which would the whole WAY easier.