Static field emit is IIFE

[robpalme]

TypeScript Version: 3.9.2

Search Terms: static field, static class members, emit

Code

// @target: esnext
// @useDefineForClassFields: true
class C {
    static x = 3;
}

Expected behavior:

Expected JS emit is:

class C {
    static x = 3;
}

Actual behavior:

Actual JS emit gets wrapped in an unwanted IIFE.

let C = /** @class */ (() => {
    class C {
        static x = 3;
    }
    return C;
})();

Playground Link:

• Correct behavior in TypeScript 3.8.3
• Correct behavior in TypeScript 3.9.0-dev.20200214
• Incorrect behavior in TypeScript 3.9.0-dev.20200215
• Incorrect behavior in TypeScript 3.9.2

Related Issues: #38374

The bug is that classes with static fields are now getting wrapped in an IIFE. This undesirable bloat occurs unconditionally. There does not appear to be anyway to turn this off to get back to standard JS emit.

The emit change was introduced by #32011

Credit to @evmar for discovering this issue.

[robpalme]

Also, I should apologize for not catching this sooner. We promised to set up CI coverage of TypeScript candidate releases. And we did set it up! Unfortunately the CI early-exited when it hit a package that wasn't ready for TypeScript 3.9, which stopped it reaching our emit-equivalence check for any of the packages. Having just disabled the early-exit, it immediately revealed this issue in the Beta 😬 We'll do better for the next release.

[robpalme]

Ok, I think I understand the full issue now.

Dead-code elimination for unused classes was previously failing for down-leveled classes with static fields. So the IIFE + magic-comment was introduced to fix this.

The remaining problem is that the fix was scoped too widely, and ends up getting applied even in cases where no down-leveling is required.

[rrdelaney]

We (Google) are also running into this issue 😞 I filed #38374 to add a flag controlling the IIFE emit, because although the emit is valuable to some users, it messes up our toolchain.

[robpalme]

Thanks for highlighting this @rrdelaney. I think these two issues are related and orthogonal.

• Introduce new flag for minifier optimization hints #38374 gives control over different flavors of down-leveling
• Static field emit is IIFE #38528 restores the ability to have lossless emit for the case of no down-leveling

[rrdelaney]

I think we might be on the same page here. The idea behind #38374 is to allow us to have lossless emit behind a flag, while still allowing the community to have optimizer hints if they want them. The IIFE doesn't work with our pipelines but is definitely helpful for a lot of people.

[clydin]

The issue here is that the ESNext target is not accounted for in the logic. In all actual current ECMAScript targets, static is down-leveled. This was definitely an oversight.

[rrdelaney]

Only emitting for downleveled code wouldn't solve Google's issue, we're still using ES2015 emit.

[clydin]

The problem demonstrated in this issue only represents when targeting ESNext and the useDefineForClassFields option is enabled. In this specific situation, static class properties are not down-leveled and are instead kept as direct members of the class. As a result, a wrapper has no real value (assuming no decorators are present) since the wrapper would only contain the class definition.