Closure Compiler是一个JavaScript优化器，它也与TypeScript(使用我们的https://github.com/angular/tsickle作为中间重写器)工作得很好。它产生最小的包，我们在Google内部使用它，并为一些Angular用户提供最小化的应用程序。
在ADVANCED_OPTIMIZATIONS模式下，Closure Compiler重命名非本地属性。它使用一个简单的规则：未加引号的属性访问可以被重命名，但带引号的属性访问不能。这可能会破坏在混合引用和非引用属性访问的情况下的程序，例如一个简单的例子：

window.foo = "hello world";
console.log(window["foo"]);

被Closure Compiler [1] 压缩为

window.a = "hello world";
console.log(window.foo); // prints "undefined"

目前，Closure Compiler将正确引用/非引用访问的责任放在作者身上。这是在这里记录的：https://developers.google.com/closure/compiler/docs/api-tutorial3#propnames
我们相信，通过TypeScript的类型检查器，我们可以标记出大多数导致属性重命名破坏用户程序的情况。我们建议引入一个选项，使带引号和不带引号的属性成为独立的、不匹配的成员。在下面的提案中，假设我们通过选项--strictPropertyNaming启用了这种行为。

将带引号和不带引号的属性视为不同的

目前，TypeScript允许对命名属性进行带引号的访问(反之亦然):

interface SeemsSafe {
    foo?: {};
}

let b: SeemsSafe = {};
b["foo"] = 1; // This access should fail under --strictPropertyNaming
b.foo = 2; // okay

此外，TypeScript 2.2中新引入的问题也存在：

interface HasIndexSig {
  [key: string]: boolean;
}
let c: HasIndexSig;
c.foo = true; // This access should fail under --strictPropertyNaming

定义不应重命名其成员的类型的类型

用户可以方便地指定一个类型，以确保属性不会被重命名。例如，当XHR返回时，JSON数据的属性访问必须不会被重命名。

// Under --strictPropertyNaming, the quotes on these properties matter.
// They must be accessed quoted, not unquoted.
interface JSONData {
  'username': string;
  'phone': number;
}

let data = JSON.parse(xhrResult.text) as JSONData;
console.log(data['phone']); // okay
console.log(data.username); // should be error under --strictPropertyNaming

结构匹配

如果两个类型的引用方式不同，它们不应该有结构匹配：

interface JSONData {
  'username': string;
}

class SomeInternalType {
  username: string;
}

let data = JSON.parse(xhrResult.text) as JSONData;
let myObj: SomeInternalType = data;  // should fail under --strictPropertyNaming
console.log(myObj.username); // would get broken by property renaming

避免混合索引签名和命名属性

可选：我们可以添加一个语义检查 .ts 输入，禁止任何类型同时具有索引签名和命名属性。

interface Unsafe {
    [prop: string]: {};
    foo?: {}; // This could be a semantic error with --strictPropertyNaming
}

let a: Unsafe = {};
a.foo = 1;
a["foo"] = 2;

请注意，交集运算符 & 仍然会击败这样的检查：

type Unsafe = {
    [prop: string]: {};
} & {
    foo?: {}; // This is uncheckable because the intersection never fails
}

我们不应该检查 .d.ts 输入，因为它们可能在没有 --strictPropertyNaming 的情况下被编译。

与库的兼容性

如果一个库是用 --strictPropertyNaming 开发的，那么生成的 .d.ts 文件应该可以在任何程序中使用，无论它是否选择启用该标志。然而有一个角落情况需要注意。
以下示例可能应该产生declarationDiagnostic,因为在没有 --strictPropertyNaming 的情况下生成的.d.ts文件在编译时会产生错误。

type C = {
  a: number;
  'a': string; // this one should probably error
  [key: string]: number;
}

一个更简单的选择是允许这种情况发生，并将其生成在 .d.ts 文件中。然后下游消费者只有在打开 --strictPropertyNaming 或 --noLibCheck 时才会收到错误。
在这里，我们对这两种选择都表示满意。

需要引号的属性名

在这种情况下，别无选择，只能给标识符加上引号：

interface JSONData {
  'hy-phen': number;
}

这在 --strictPropertyNaming 下仍然有效，但含义是这样的标识符被迫不可重命名，因为没有不带引号的语法来声明它。这似乎没问题，只是为了这样的名称而失去优化，我们认为这种情况很少见。

属性重命名安全性

还有一些情况仍然不安全：

• any 类型仍然关闭类型检查，包括检查带引号和不带引号的访问
• 在没有 --strictPropertyNaming 开发的库中使用的未加引号的标识符不应被重命名(例如 document.getElementById )。Closure Compiler已经有一个“externs”机制来防止重命名。在TypeScript代码中，这些属性不会被重命名，但现在的情况与今天的情况相同。