Introduce new flag for minifier optimization hints

Search Terms

Optimization
Minifier
Bundler
IIFE
Wrapper
Terser

Suggestion

TypeScript 3.9 pulled in PR #32011, which tailors TypeScript's output for optimization with minifiers such as Terser. This PR definitely goes in the right direction for optimizing TypeScript's emit for most users, but doesn't necessarily work for all toolchains out there. At Google we have optimization processes after TypeScript compilation that use static analysis to look for classes, do some rough type-checking, and for example rename class properties and drop methods. The wrapper introduced in TypeScript 3.9 hinders our ability to analyze these classes.

We'd like to propose a new flag to toggle this behavior, which I'll call --add-optimization-hints for now. This flag would control if TypeScript decides to emit these hints for optimizers and bundlers, which is not necessarily limited to the /** @class */ form introduced in TypeScript 3.9. For users such as Google, we can disable this flag and instead rely on our own optimizers to handle this, but users piping directly through Webpack and Terser can still receive the benefits from #32011.

Use Cases

Removing IIFE Wrapper for ES2015 Classes

Expanding on our toolchain a bit from above, at Google we use a combination of tsickle, closure-compiler, and other tools to optimize our TypeScript code. Tsickle is used to add type annotations and use the goog.module module system to TypeScript's emit such that Closure Compiler can optimize the code. Using the TypeScript 3.9 RC which emits IIFE wrappers around ES2015 classes Closure Compiler is unable to understand that this is an alias for the inner class. By setting --add-optimization-hints=false we would be able to statically analyze TypeScript's output without doing additional special processing.

Adding Further Optimization Hints

PR #32011 isn't the first to request optimization hints from the TypeScript output, for example #13721 requested a /** #pure */ annotation as well, and there could be more in the future that TypeScript would like to hint at. Adding this flag allows TypeScript to produce messier code that is less similar to the input, but more compatible with bundlers and minifiers.

Examples

This would be a new flag for the TypeScript compiler. Assuming TypeScript 3.9 is being used, given the input:

// input.ts
class C {
  static prop = 10;

  getProp() {
    return C.prop;
  }
}

Compiling with tsc --add-optimization-hints=true:

// output.js
"use strict";
let C = /** @class */ (() => {
    class C {
        getProp() {
            return C.prop;
        }
    }
    C.prop = 10;
    return C;
})();

Compiling with tsc --add-optimization-hints=false:

// output.js
"use strict";
class C {
    getProp() {
        return C.prop;
    }
}
C.prop = 10;

Checklist

My suggestion meets these guidelines:

• This wouldn't be a breaking change in existing TypeScript/JavaScript code
• This wouldn't change the runtime behavior of existing JavaScript code
• This could be implemented without emitting different JS based on the types of the expressions
• This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, etc.)
• This feature would agree with the rest of TypeScript's Design Goals.

Beginne mit der Prüfung von PR #32011 und des bestehenden optimization-hint-Emit-Verhaltens des TypeScript-Compilers und verwende dabei die Beispiele für input.ts und output.js aus dem Issue als Grundlage. Lege fest, wie das vorgeschlagene Flag die ausgegebene Ausgabe verändert, und verifiziere, dass sowohl die aktivierten als auch die deaktivierten Fälle mit den dokumentierten Beispielen übereinstimmen.