TypeScript 3.2 正式版发布

时间 2019-11-10

标签 typescript 3.2 正式发布繁體版

原文原文链接

本文为公众号“TypeScript社区（QQ 群号 390037547）”原创翻译，转载请注明出处！不然追究法律责任！node

TypeScript 3.2 正式版于 2018 年 11 月 29 日发布。此版本新增特性及变动事项以下：redis

• 严格的 bind、call 和 apply
• 泛型类型上的对象展开操做
• 泛型类型上的对象剩余操做
• 基于 Node.js 的 tsconfig.json 继承解决方案
• 使用“--showConfig”来对 tsconfig.json 进行诊断
• BigInt
• JavaScript 中的 Object.defineProperty 声明
• 错误信息改进
• 标记化联合类型的类型收窄改进
• 编辑改进
• 破坏性变动和弃用项
• NuGet 和 Visual Studio 2015 用户注意事项
• 下一步是什么typescript

下面为你们带来 TypeScript 官方博客的翻译：
TypeScript 3.2 is here today!
今天 TypeScript 3.2 到来了！
If you’re unfamiliar withTypeScript, it’s a language that brings static type-checking to JavaScript so that you can catch issues before you even run your code – or before you even save your file. It also includes the latest JavaScript features from the ECMAScript standard on older browsers and runtimes by compiling those features into a form that they understand. But beyond type-checking and compiling your code, TypeScript also provides tooling in your favorite editor so that you can jump to the definition of any variable, find who’s using a given function, and automate refactorings and fixes to common problems. TypeScript even provides this for JavaScript users (and can also type-check JavaScript code typed withJSDoc), so if you’ve used editors like Visual Studio or Visual Studio Code on a .js file, TypeScript is powering that experience.
若是你不熟悉 TypeScript，它是一门语言，为JavaScript 带来了静态类型检查以便你可以在运行代码前甚至是保存文件前捕获问题。它还包括来自 ECMAScript 标准的最新的 JavaScript 特性，这些特性可以运行在老版本的浏览器或运行时上——经过将这些新特性编译为老版本浏览器或运行时理解的形式来实现。可是，除了类型检查和编译你的代码，TypeScript 还提供了你最喜欢的编辑器中的工具以便你能够跳转到任何变量的定义位置，找到谁正在使用某个函数，以及自动地重构和修复常见的问题。TypeScript 甚至为 JavaScript用户提供了这些功能特性（也能够对使用 JSDoc类型化后的 JavaScript 代码进行类型检查），因此若是你使用如 Visual Studio 或者 Visual Studio Code 这样的编辑器来编辑 js 文件，TypeScript 正在为这些体验提供动力。
To get started with the language itself, check out typescriptlang.org to learn more.
要开始使用这个语言，请查看这里typescriptlang.org 以了解更多信息。
But if you want to try TypeScript 3.2 out now, you can get it through NuGet or via npm by running
可是若是你想要如今就尝试 TypeScript 3.2，你能够经过 NuGet 或者经过npm（经过运行如下命令）来获取它：
npm install -g typescript
You can also get editor support for
你也能够得到对如下编辑器的支持：
• Visual Studio 2017 (for version 15.2 or later).
Visual Studio 2017（版本 15.2 或更高版本）。
• Visual Studio 2015 (which requires update 3).
Visual Studio 2015（须要更新版 3）。
• For Visual Studio Code by installing the Insiders release until the full release provides it.
对于 Visual Studio Code，在提供完整发布版以前经过安装预览发布版来获取。
• Sublime Text 3 via PackageControl.
Sublime Text 3 经过 PackageControl 获取。
Other editors may have different update schedules, but should all have TypeScript available soon.
其它编辑器会有不一样的更新计划，但都会很快就有可用的 TypeScript。
We have some important information below for NuGet users and Visual Studio 2015 users, so please continue reading if you use either product.
下面咱们有一些对 NuGet 和 Visual Studio 2015用户而言很是重要的信息，因此若是你使用这两个产品，请继续阅读。
Below we have a bit about what’s new in 3.2.
下面是关于 3.2 中新增的内容。
• strictBindCallApply
严格的 bind、call 和 apply
• Object spread on generic types
泛型类型上的对象展开
• Object rest on generic types
泛型类型上的对象剩余操做
• Node.js-based resolution for tsconfig.json inheritance
基于 Node.js 的 tsconfig.json 继承解决方案
• Diagnosing tsconfig.json with --showConfig
使用“--showConfig”来对 tsconfig.json 进行诊断
• BigInt
大整数
• Object.defineProperty declarations in JavaScript
JavaScript 中的 Object.defineProperty 声明
• Error message improvements
错误信息改进
• Improved narrowing for tagged unions
标记式联合类型的类型收窄改进
• Editing improvements
编辑改进
• Breaking changes and deprecations
破坏性变动和弃用项
 A note for NuGet and Visual Studio 2015 users
给 NuGet 和 VisualStudio 2015 用户的提示
• What’s next
下一步是什么
strictBindCallApply
严格的 bind、call 和 apply
As you might’ve guessed from the title of this section, TypeScript 3.2 introduces stricter checking for bind, call, and apply. But what does that mean?
正如你可能从这个标题所猜想的那样，TypeScript3.2 引入了对 bind、call 和 apply 更严格的检查。但那意味着什么呢？
Well, in JavaScript, bind, call, and apply are methods on functions that allow us to do things like bind this and partially apply arguments, call functions with a different value for this, and call functions with an array for their arguments.
在 JavaScript 中，bind、call 和 apply 是在函数上的方法，它们容许咱们作这些事情——绑定 this并应用部分参数，使用一个不一样的 this 值来调用函数，以及使用承载函数参数的数组来调用函数。
Unfortunately, in its earlier days, TypeScript lacked the power to model these functions, and bind, call, and apply were all typed to take any number of arguments and returned any. Additionally, ES2015’s arrow functions and rest/spread arguments gave us a new syntax that made it easier to express what some of these methods do – and in a more efficient way as well.
不幸的是，在早些时期，TypeScript 缺乏对这些函数建模的能力，而且 bind、call 和 apply 都被类型化为接收任意数量的参数并返回 any 的函数。另外，ES2015 的箭头函数和剩余/展开参数带给咱们一个新的语法，它使得表达这些方法是作什么的变得更容易也更高效。
Still, demand to model these patterns in a type-safe way led us to revisit this problem recently. We realized that two features opened up the right abstractions to accurately type bind, call,and apply without any hard-coding:
尽管如此，要求以类型安全的方式对这些模式进行建模，使得咱们最近又从新审视了这个问题。咱们意识到两个特性开辟了正确的抽象来精确地标注 bind、call 和 apply 的类型而无需任何硬编码：express

this parameter types from TypeScript 2.0

来自 TypeScript 2.0 的 this 参数类型npm

Modeling parameter lists with tuple types from TypeScript 3.0

来自 TypeScript 3.0 的使用元组类型模拟参数列表
Combined, the two of of them can ensure our uses of bind, call, and apply are more strictly checked when we use a new flag called strictBindCallApply. When using this new flag,the methods on callable objects are described by a new global type called CallableFunction which declares stricter versions of the signatures for bind, call,and apply. Similarly, any methods on constructable (but not callable) objects are described by a new global type called NewableFunction.
结合起来，当咱们使用一个新的称做 strictBindCallApply 的标志时，这两项可以确保咱们对 bind、call 和 apply 的使用可以被严格地检查。当使用这个新标志时，可调用地对象上的方法被一个被称为 CallableFunction 的全局类型所描述，该类型声明了 bind、call 和 apply 签名的更严格的版本。相似的，可构建（但不是可调用）对象上的任何方法都是被一个被称为 NewableFunction 的全局类型所描述。
As an example, we can look at how Function.prototype.apply acts under this behavior:
做为例子，咱们能够看到在这个行为之下 Function.prototype.apply 是如何表现的：
function foo(a:number, b:string):string{
return a + b;
}编程

// My secret revealed, I have two clones!
let shallowCopyOfPerson = { ...person };
let shallowCopyOfPersonWithDifferentLocation = {...person, location:"Seattle"};
TypeScript does a pretty good job here when it has enough information about the type. The type system closely tries to model the behavior of spreads and overwrites new properties, tries to ignore methods, etc. But unfortunately up until now it wouldn’t work with generics at all.
当有足够多的关于类型的信息时，TypeScript 能工做得很好。类型系统尝试模拟展开行为并覆写新的属性，尝试忽略方法等。但不幸的是，直到目前它仍彻底没法用于泛型。
function merge<T,U>(x: T,y:U) {
// Previously an error!
return { ...x, ...y };
}
This was an error because we had no way to express the return type of merge. There was no syntax (nor semantics) that could express two unknown types being spread into a new one.
这曾经是一个错误由于咱们没法表示 merge 的返回类型。没有语法（或者语义）可以表示两个未知类型展开到一个新的类型中。
We could have come up with a new concept in the type system called an “object spread type”, and in fact we had a proposal for exactly that. Essentially this would be a new type operator that looks like { ...T,...U } to reflect the syntax of an object spread.
咱们可能会想出一个新的概念，在类型系统中称为“对象展开类型”，事实上咱们的确有那么个提案。实质上，它会成为一个新的，看起来像“{...T,...U }” 这样的类型操做符以反映一个对象展开的语法。
When both T and U are known, that type would flatten down to some new object type.
当T 和 U 都是未知的时候，那个类型将会扁化为某些新的对象类型。
However, this is pretty complex and requires adding new rules to type relationships and inference. While we explored several different avenues, we recently arrived at two conclusions:
然而，这是至关复杂的，且须要添加新的规则到类型关系和推断中。当咱们考察了几种不一样的方式后，咱们最近获得两个结论：数组

For most uses of spreads in JavaScript, users were fine modeling the behavior with intersection types (i.e. Foo & Bar).

JavaScript中使用的大多数展开，用户可使用交叉类型（例如 Foo& Bar）来模拟该行为。浏览器

Object.assign – a function that exhibits most of the behavior of spreading objects – is already modeled using intersection types, and we’ve seen very little negative feedback around that.

Object.assign——一个展现了展开对象的绝大多数行为的函数——已经使用交叉类型进行模拟，而且咱们未看到关于它的负面反馈。
Given that intersections model the common cases, and that they’re relatively easy to reason about for both users and the type system, TypeScript 3.2 now permits object spreads on generics and models them using intersections:
鉴于交叉类型模拟了常见的情形，且对于用户和类型系统而言相对容易推理，TypeScript 3.2 如今容许对泛型进行对象展开并使用交叉类型来模拟它们：
// Returns 'T & U'
function merge<T,U>(x:T, y:U) {
return{ ...x, ...y };
}安全

// Returns '{ name: string, age: number,greeting: string } & T'
function foo<T>(obj:T) {
let person = {

name: "Daniel",
    age:26

};

return { ...person, greeting:"hello", ...obj };
}
Object rest on generic types
泛型类型上的对象剩余操做
Object rest patterns aresort of the dual of object spreads. Instead of creating a new object with some extra/overridden properties, it creates a new object that lacks some specified properties.
对象剩余模式有点像双重的对象展开。它建立一个新的缺乏某些特定属性的对象，而不是建立一个新的带有额外的/被覆盖的属性的对象。
let { x, y, z, ...rest } = obj;
In the above, the most intuitive way to look at this code is that rest copies over all the properties from obj apart from x, y, and z. For the same reason as above, because we didn’t have a good way to describe the type of rest when obj is generic, we didn’t support this for a while.
如上，最直观的看待这个代码的方式是 rest 从 obj 复制除了 x、y 和 z 以外的全部属性。因为上述相同的缘由，当 obj 是泛型时，咱们没有一个好的方式来描述 rest 的类型，咱们暂时不支持这个。
Here we also considered a new rest operator, but we saw we already had the facilities for describing the above: our Pick and Exclude helper types in lib.d.ts To reiterate, ...rest basically picks off all ofthe properties on obj except for x, y, and z in the following example:
这里咱们也考虑过一个新的剩余运算符，但咱们看到咱们已经有了描述上述情形的装备：lib.d.ts 中的 Pick 和 Exclude 帮助器类型。为了重申这一点，下面例子中 ...rest 拾取 obj 中除了 x、y 和 z 的全部属性：
interface XYZ{ x:any; y:any; z:any; }

function dropXYZ<T extends XYZ>(obj:T) {
let { x, y, z, ...rest } = obj;
return rest;
}
If we want to consider the properties of T (i.e. keyof T) except for x, y, and z, we can write Exclude<keyof T, "x" | "y" | "z">. We then want to pick those properties back off of the original type T, which gives us
若是咱们要考虑 T（例如，keyof T）中除了 x、y 和 z 以外的属性，咱们能够写 Exclude<keyof T, "x" | "y" |"z">。咱们而后想要把原来的那个类型 T 的那些属性取回来，这让我获得：
Pick<T, Exclude<keyof T, "x" |"y" | "z">>`.
While it’s not the most beautiful type (hey, I’m no George Clooney myself), we can wrap it in a helper type like DropXYZ:
虽然它不是最好看的类型，咱们能够把它包装到一个帮助器类型中，如 DropXYZ：
interface XYZ { x:any; y:any; z:any; }

type DropXYZ<T> = Pick<T, Exclude<keyof T, keyof XYZ>>;

function dropXYZ<T extends XYZ>(obj:T):DropXYZ<T> {
let { x, y, z, ...rest } = obj;
return rest;
}
Configuration inheritance via node_modules packages
经过 node_modules 包实现配置继承
For a long time TypeScript has supported extending tsconfig.json files using the extends field.
很早之前 TypeScript 就已经支持使用 extends 字段来扩展 tsconfig.json 文件。
{
"extends":"../tsconfig-base.json",
"include": ["./*/"]
"compilerOptions": {

// Override certain options on a project-by-projectbasis.
   "strictBindCallApply":false,

}
}
This feature is very useful to avoid duplicating configuration which can easiy fall out of sync, but it really works best when multiple projects are co-located in the same respository so that each project can reference a common “base” tsconfig.json.
这个特性对于避免重复配置是很是有用的，这些重复的配置很容易失去同步，可是当多个项目共同位于同一个储存库中时，它确实是最有效的，这样每一个项目均可以引用一个通用的基础 tsconfig.json。
But for some teams, projects are written and published as completely independent packages. Those projects don’t have a common file they can reference, so as a workaround, users could create a separate package and reference that:
可是对于某些团队，项目是做为彻底独立的包来编写和发布的。那些项目没有一个通用的文件能够供他们引用，所以，做为一个变通方案，用户能够建立一个单独的包并引用它：
{
"extends": "../node_modules/@my-team/tsconfig-base/tsconfig.json",
"include": ["./*/"]
"compilerOptions": {

// Override certain options on a project-by-projectbasis.
   "strictBindCallApply":false,
}

}
However,climbing up parent directories with a series of leading ../s and reaching directly into node_modules to grab a specific file feels unwieldy.
然而，经过一系列前导的 ../ 爬升到父目录并进入到 node_modules 来获取特定的文件显得很粗笨。
TypeScript 3.2 now resolves tsconfig.jsons from node_modules. When using a bare path for the "extends" field in tsconfig.json,TypeScript will dive into node_modules packages for us.
TypeScript 3.2 如今从 node_modules 中解析 tsconfig.json。当在 tsconfig.json 中为“extends”字段使用一个裸路径（没有前导的“../”）时，TypeScript 将会为咱们潜入到 node_modules 包中。
{
"extends":"@my-team/tsconfig-base",
"include": ["./*/"]
"compilerOptions": {

// Override certain options on a project-by-projectbasis.
   "strictBindCallApply":false,

}
}
Here,TypeScript will climb up node_modules folders looking for a @my-team/tsconfig-base package. For each of those packages, TypeScript will first check whether package.json contains a "tsconfig" field, and if it does,TypeScript will try to load a configuration file from that field. If neither exists, TypeScript will try to read from a tsconfig.json at the root. This is similar to the lookup process for .js files in packages that Node uses, and the .d.ts lookup process that TypeScript already uses.
在这里，TypeScript 将会爬升到 node_modules 文件夹查找一个叫作 @my-team/tsconfig-base 的包。对于每个包，TypeScript 将会首先检查 package.json 是否包含一个“tsconfig”字段，若是有，TypeScript 将会尝试从根据那个字段加载配置文件。若是都没有，TypeScript 将会尝试从根目录的 tsconfig.json 读取。这和查找 Node 使用的 .js 文件的过程以及查找TypeScript 已经使用的 .d.ts 文件的过程类似。
This feature can be extremely useful for bigger organizations, or projects with lots of distributed dependencies.
这个特性对于大型组织或者有许多分布式依赖的项目特别的有用。
Diagnosing tsconfig.json with --showConfig
使用 --showConfig 来诊断 tsconfig.json
tsc, the TypeScript compiler, supports a new flag called --showConfig. When running tsc --showConfig, TypeScript will calculate the effective tsconfig.json (after calculating options inherited from the extends field) and print that out.This can be useful for diagnosing configuration issues in general.
TypeScript 编译器 tsc 支持新的称做 --showConfig 的标志。当运行 tsc --showConfig 时，TypeScript 将会计算有效的 tsconfig.json（在计算继承于 extends 字段的选项以后）并把它们打印出来。通常这对于诊断配置问题颇有用。
BigInt
大整数
BigInts are part of an upcoming proposal in ECMAScript that allow us to model theoretically arbitrarily large integers. TypeScript 3.2 brings type-checking for BigInts, as well as support for emitting BigInt literals when targeting esnext.
BigInt 是即将到来的 ECMAScript提案中的一部分，它容许咱们模拟理论上任意大的整数。当将编译目标设定为 esnext 时，TypeScript3.2 为BigInt 带来了类型检查以及支持生成 BigInt 字面量。
BigInt support in TypeScript introduces a new primitive type called the bigint (all lowercase). You can get a bigint by calling the BigInt() function or by writing out a BigInt literal by adding an n to the end of any integer numeric literal:
在 TypeScript 中支持 BigInt，引入了一个新的称为 bigint （所有小写）的基本类型。你能够经过调用 BigInt() 函数或者经过直接在任意整数字面量的后面加上一个 n 来书写 BigInt 字面量而获得一个 bigint。
let foo: bigint = BigInt(100);// the BigInt function
let bar:bigint = 100n; // a BigInt literal

// Slaps roof of fibonacci function
// This bad boy returns ints that can getso big!
function fibonacci(n:bigint) {
let result = 1n;
for (let last = 0n, i = 0n; i < n; i++) {

const current = result;
    result += last;
    last = current;
}

return result;
}

fibonacci(10000n)
While you might imagine close interaction between number and bigint, the two are separate domains.
虽然你可能想要 number 和 bigint 之间紧密交互，但它们两个属于不一样的领域。
declare let foo:number;
declare let bar:bigint;

foo = bar;// error: Type 'bigint' is not assignable to type 'number'.
bar = foo;// error: Type 'number' is not assignable to type 'bigint'.
As specified in ECMAScript, mixing numbers and bigints in arithmetic operations is an error. You’ll have to explicitly convert values to BigInts.
如在 ECMAScript 中规定的那样，在算术运算中混合 number 和 bigint 是错误的。你将必须显式地把值转换为 BigInt。
console.log(3.141592*10000n); //error
console.log(3145*10n); //error
console.log(BigInt(3145) *10n); //okay!
Also important to note is that bigints produce a new string when using the typeof operator: the string "bigint". Thus, TypeScript correctly narrows using typeof as you’d expect.
还须要关注的一点是，当对 BigInt 使用 typeof 运算符时将会产生一个新的字符串——“bigint”。所以，如你所期盼的那样，TypeScript 正确地收窄了 typeof。
function whatKindOfNumberIsIt(x:number | bigint) {
if(typeof x === "bigint") {

console.log("'x' is a bigint!");

}
else{

console.log("'x' is a floating-point number");
}

}
We’d like to extend a huge thanks to CalebSander for all the work on this feature. We’re grateful for the contribution, and we’re sure our users are too!
咱们很是感谢 Caleb Sander 为这个特性所作的全部工做。咱们很感谢这个贡献，咱们也确信咱们的用户也是如此！
Caveats
注意事项
As we mentioned, BigInt support is only available for the esnext target. It may not be obvious, but because BigInts have different behavior for mathematical operators like +, -, *,etc., providing functionality for older targets where the feature doesn’t exist (like es2017 and below) would involve rewriting each of these operations. TypeScript would need to dispatch to the correct behavior depending on the type, and so every addition, string concatenation,multiplication, etc. would involve a function call.
如咱们所提到的，BigInt 的支持仅对 esnext 做为编译目标时可用。它可能不明显，可是由于BigInt 对于算术运行符如 +、-、 * 等有不一样的行为，为那些不存在该特性的老版本目标（如 es2017 及如下版本）提供该功能将会涉及重写这每个运算符。TypeScript 将须要依据类型调度正确的行为，因此每个加法，字符串链接，乘法等，将会涉及到一个函数调用。
For that reason, we have no immediate plans to provide downleveling support. On the bright side, Node 11and newer versions of Chrome already support this feature, so you’ll be able touse BigInts there when targeting esnext.
鉴于此，咱们没有当即计划提供降级的支持。可喜的是，Node 11 和更新版本的 Chrome 已经支持这个特性，因此当将编译目标设定为 esnext 时你将可以在这些平台使用 BigInt。
Certain targets may includea polyfill or BigInt-like runtime object. For those purposes you may want toadd esnext.bigint to the lib setting in your compiler options.
某些编译目标可能包含有兼容包（polyfill）或者相似 BigInt 的运行时对象。出于此目的你可能想要添加 esnext.bigint 到你的编译器选项的 lib设置中。
Object.defineProperty declarations in JavaScript
JavaScript 中的 Object.defineProperty 声明
When writing in JavaScriptfiles (using allowJs), TypeScript now recognizes declarations that use Object.defineProperty. This means you’ll get better completions, and stronger type-checking when enabling type-checking in JavaScript files (by turning on the checkJs option or adding a //@ts-check comment to the top of your file).
当编写 JavaScript 时（使用 allowJs 标志），TypeScript 如今能识别使用 Object.defineProperty 的声明了。这意味着你将获得更好的代码完成，以及当启用在JavaScript 中进行类型检查（经过打开 checkJs 选项或者在文件的顶部添加 //@ts-check 注释来开启）时更强的类型检查。
// @ts-check

let obj = {};
Object.defineProperty(obj,"x", { value:"hello", writable:false });

obj.x.toLowercase();
// ~~~
// error:
// Property 'toLowercase' does not exist on type 'string'.
// Did you mean 'toLowerCase'?

obj.x = "world";
// ~
// error:
// Cannot assign to 'x' because it is a read-only property.
Error message improvements
错误消息改进
We’re continuing to push improvements in the error experience inTypeScript. Here’s a few things in TypeScript 3.2 that we believe will make the language easier to use.
咱们持续地推动 TypeScript 中的错误体验方面的改进。下面的这些是在 TypeScript 3.2 中咱们相信将会使这个语言更易于使用。
• Better missing property errors (and cleaner missing attributes in JSX)
更好的属性缺失错误提示（以及 JSX 中的更简洁的特性缺失提示）
• Better error spans in arrays and arrow functions
数组和箭头函数中更好的错误提示（错误位置标示）

• Error on most-overlapping types in unions (a.k.a. “pick most overlappy type”)
联合类型中覆盖最广的类型的错误（又名“选取最广覆盖类型”）

TypeScript 3.2 以前的报错信息

TypeScript 3.2 的报错信息
• Related spans when a typed this is shadowed
当一个具备类型的 this 被隐蔽时的相对跨度提示

TypeScript 3.2 以前的报错信息

TypeScript 3.2 的报错信息
• “Did you forget a semicolon?” on parenthesized expressions on the next line
“你忘记了分号吗？”在下一行中的括号表达式上的提示

• More specific messages when assigning to const / readonly bindings
当赋值给 const / readonly 时更具体的信息

TypeScript 3.2 以前的报错信息

TypeScript 3.2 的报错信息
• More accurate message when extending complex types
扩展复杂类型时更精准的信息

TypeScript 3.2 以前的报错信息

TypeScript 3.2 的报错信息
• Use relative module names in error messages
在错误信息中使用相对模块名称

TypeScript 3.2 以前的报错信息

TypeScript 3.2 的报错信息
Thanks to Kingwl, a-tarasyuk, and prateekgoel who helped out on some of these improvements.
感谢 Kingwl、a-tarasyuk 和 prateekgoel 对这些改进所提供的帮助。
Improved narrowing for tagged unions
改进了的标记式联合类型的收窄
TypeScript 3.2 makes narrowing easier by relaxing rules for what’s considered a discriminant property. Common properties of unions are now considered discriminants as long as they contain some singleton type (e.g. a string literal, null, or undefined), and they contain no generics.
TypeScript 3.2 经过放宽断定什么是判别属性的规则使类型收窄变得更容易。联合类型的常规属性如今被认为是判别属性——只要它们包含某些孤立类型（如，字符串字面量，null 或 undefined）且不包含泛型。
As a result, TypeScript 3.2 considers the error property in the following example to be a discriminant, whereas before it wouldn’t since Error isn’t a singleton type. Thanks to this, narrowing works correctly in the body of the unwrap function.
结果，TypeScript 3.2 认为如下例子中的 error 属性是一个判别属性，而在此前的版本中则不是，由于 Error不是一个孤立类型。因为这点，unwrap 函数体中的收窄可以正确地工做。
type Either<T>=
| { error:Error; data:null}
| { error:null; data:T};

function unwrap<T>(result:Either<T>) {
if(result.error) {

// Here 'error' is non-null
   throw result.error;

}

// Now 'data' is non-null
return result.data;
}
Editing improvements
编辑改进
The TypeScript project doesn’t simply consist of a compiler/type-checker. The core components of the compiler also provide a cross-platform open-source language service that can power “smarter” editor features like go-to-definition, find-all-references, and a number of quick fixes and refactorings. TypeScript 3.2 brings some small quality of life improvements.
TypeScript 项目不是简单的包含一个编译器/类型检查器而已。编译器的核心组件还提供了一个跨平台开源的语言服务，它能带来更“聪明”的编辑器特性，如转到定义，查找全部引用，以及许多快速修复和重构。TypeScript 3.2 为生活质量带来了一些小提高。
Quick fixes
快速修复
Implicit any suggestions and “inferfrom usage” fixes
修复隐式 any 建议和“从使用推导”
We strongly suggest users take advantage of stricter checking when possible. noImplicitAny is one of these stricter checking modes, and it helps ensure that your code is as fully typed as possible which also leads to a better editing experience.
咱们强烈建议用户在可能的时候利用更严格的检查。noImplicitAny 是这些更严格的检查模式之一，且它可以帮助保证你的代码尽量彻底地类型化同时也可以带来更好的编辑体验。
Unfortunately it’s not all roses for existing codebases. noImplicitAny is a big switch across codebases which can lead to a lot of error messages and red squiggles in your editor as you type code. The experience can be jarring to turn on just to find out which variables need types.
不幸的是对于现有的代码库来讲，这并不都是好的。noImplicitAny 是一个跨代码库的大开关，当你输入代码时，它会致使编辑器中出现大量的错误消息和红色波浪线。只是为了找出哪一个变量须要类型，这种体验可能会让人震惊。
In this release, TypeScript produces suggestions for most variables and parameters that would have been reported as having implicit any types. When an editor reports these suggestions, TypeScript also provides a quick fix to automatically infer the types for you.
在这个版本中，TypeScript 为大多数变量和参数产生建议，这些变量和参数将被报告为具备隐式any 类型。当编辑器报告这些建议时，TypeScript也提供一个快速修复来为你自动推导这些类型。

This can make migrating an existing codebase to TypeScript even easier, and we expect it will make migrating to noImplicitAny a breeze.
这使得迁移现有代码库到 TypeScript 更容易，同时咱们但愿它可以使得迁移到noImplicitAny 变得垂手可得。
Going a step further,TypeScript users who are type-checking their .js files using checkJs or the // @ts-check comments can now also getthe same functionality with JSDoc types!
更进一步，经过使用 JSDoc类型，那些使用checkJs 或者 // @ts-check 注释来对他们的 .js文件进行类型检查的 TypeScript 用户如今一样能够获得相同的功能。

Other fixes
其它修复
TypeScript 3.2 also brings two smaller quick fixes for small mistakes.
TypeScript 3.2 一样为小错误带来了两个更小的快速修复。
• Add a missing new when accidentally calling a constructor.
当意外地调用了构造函数时添加一个缺失的new。
• Add an intermediate assertion to unknown when types are sufficiently unrelated.
当类型彻底无关时添加一个中间断言到unknown。
Thanks to GitHub users iliashkolyar and ryanclarke respectively for these changes!
感谢 GitHub 用户 iliashkolyar 和 ryanclarke 分别为这些改变作的贡献。
Improved formatting
改进的格式化
Thanks to saschanaz,TypeScript is now smarter about formatting several different constructs. Listing all of them might be a bit cumbersome, but you can take a look at the pull request here.
感谢 saschanaz，TypeScript 如今对于格式化多个不一样的结构更加的聪明了。列出全部的这些可能会有点繁重，可是你能够在这里查看拉取请求。
Breaking changes and deprecations
破坏性变动和弃用项
lib.d.ts changes
lib.d.ts 的变动
TypeScript has recently moved more to generating DOM declarations in lib.d.ts by leveraging IDL files provided by standards groups. Upgraders should note take note of any issues they encounter related to the DOM and report them.
TypeScript 最近经过利用标准组提供的 IDL 文件，已经在 lib.d.ts中生成更多的 DOM 声明。升级者应注意他们遇到的与DOM相关的任何问题并报告它们。
More specific types
更具体的类型
Certain parameters no longer accept null, or now accept more specific types as per the corresponding specifications that describe the DOM.
某些参数再也不接受 null，或者按照那些描述 DOM的对应的规范如今接受更具体的类型。
More platform-specific deprecations
更多特定于平台的弃用项
Certain properties that are WebKit-specific have been deprecated. They are likely to be removed in a new version.
某些 WebKit 特定的属性已经被弃用。在新版本中它们极可能被移除。
wheelDelta and friends have been removed.
wheelDelta 及其关联项已经被移除
wheelDeltaX, wheelDelta, and wheelDeltaZ have all been removed as they are deprecated properties on WheelEvents.
wheelDeltaX、wheelDelta 和 wheelDeltaZ 都已被移除，由于它们是WheelEvent 上的弃用属性。
As a solution, you can use deltaX, deltaY, and deltaZ instead. If older runtimes are a concern, you can include a file called legacy.d.ts in your project and write the following in it:
你可使用 deltaX、deltaY 和 deltaZ 来替代做为一个解决方案。若是要兼顾更旧版本的运行时，你能够在项目中包含一个叫 legacy.d.ts 的文件并在其中编写以下内容：
// legacy.d.ts

interface WheelEvent {

readonly wheelDelta:number;
readonly wheelDeltaX:number;
readonly wheelDeltaZ:number;

}
JSX resolution changes
JSX 解决方案的变动
Our logic for resolving JSX invocations has been unified with our logic for resolving function calls. While this has simplified the compiler codebase and improved some use-cases, there may be some differences which we may need to reconcile. These changes are likely unintentional so they are not breaking changes per se, but upgraders should note take note of any issues they encounter and report them.
咱们用于解析 JSX 调用的逻辑已经统一为使用用于解析函数调用的逻辑。虽然这简化了编译器代码库并改进了一些用例，可是咱们可能须要调解某些差别。这些变动多是无心的，故它们自己没有破坏变动，可是升级者应注意他们遇到的任何问题并报告它们。
A note for NuGet and Visual Studio 2015
NuGet 和 Visual Studio 2015 要注意的一点
We have some changes comingin TypeScript 3.2 for NuGet and VS2015 users.
在 TypeScript 3.2 中咱们为 NuGet 和 VS 2015的用户带来了一些变化。
First, TypeScript 3.2 and future releases will only ship an MSBuild package, and not a standalone compiler package. Second, while our NuGet packages previously shipped with the Chakra JavaScript engine to run the compiler, the MSBuild package now depends on an invokable version of Node.js to be present. While machines with newer versions of Visual Studio 2017 (versions 15.8 and above) will not be impacted, some testing / CI machines, users with Visual Studio 2015, and users of Visual Studio 2017 15.7 and below may need to install Node.js directly from the site, through Visual Studio 2017 Build Tools (read more here), or via a redistribution of Node.js over NuGet. Otherwise, upgrading toTypeScript 3.2 might result in a build error like the following:
首先，TypeScript 3.2 及未来的版本将只发布一个MSBuild 包而不是一个独立的编译器包。其次，虽然之前咱们的 NuGet 包伴随着 Chakra JavaScript 引擎一块儿发布以运行编译器，可是MSBuild 包如今将以依赖于一个可调用的Node.js 版本的形式出现。虽然那些更新的版本的Visual Studio 2017（版本 15.8 及以上）的机器不会受影响，可是某些测试 / CI 机器、Visual Studio 2015 的用户以及 Visual Studio 2017 15.7 版本和更低版本的用户可能须要直接从站点安装 Node.js，经过 Visual Studio 2017 构建工具（了解更多），或者经过在 NuGet 上分发的Node.js 来安装。不然，更新到TypeScript 3.2可能会形成以下的构建错误：
The build task could not find node.exe which is required to run the TypeScript compiler. Please install Node and ensure that the system path contains its location.
构建任务没法找到 node.exe，它是运行 TypeScript编译器所必需的。请安装 Node 并确保系统环境变量中的“path”包含了它的位置。
Lastly, TypeScript 3.2 will be the last TypeScript release with editor support for Visual Studio 2015 users. To stay current with TypeScript, we recommend upgrading to Visual Studio 2017 for the latest editing experience.
最后，TypeScript 3.2 将会是支持 Visual Studio 2015 用户的最后一个 TypeScript 版本。为了保持与 TypeScript 版本一致，咱们推荐升级到 Visual Studio 2017 以得到最新的编辑体验。
What’s next
下一步是什么
Our next release of TypeScript is slated for the end of January. Some things we’ve got planned on the horizon are partial type argument inference and a quick fix to scaffold out declaration files that don’t exist on DefinitelyTyped. While this list is influx, you can keep track of our plans on the TypeScript Roadmap.
咱们的下一个 TypeScript 版本预计是在（2019 年）一月末。咱们已经有了眉目的一些事情是：部分类型参数推断和快速修复以生成那些DefinitelyDyped 中不存在的声明文件。虽然这个列表在不断变化，但你能够在TypeScript 路线图上跟踪咱们的计划。
We hope that TypeScript 3.2 makes your day-to-day coding more enjoyable, whether it comes to expressivity, productivity, or ease-of-use. If you’re enjoying it, drop us a line on Twitterat @typescriptlang; and if you’ve got ideas on what we should improve, file an issue on GitHub.
不管是表现力，生产力仍是易用性，咱们但愿TypeScript 3.2 能让你的平常编程更开心。若是你喜欢它，请在 Twitter 上给 @typescriptlang 留言；若是你对咱们应该做何改进有想法，请在 GitHub 上建立一个 issue 告知咱们。
Happy hacking!
嗨起来吧！
– Daniel Rosenwasser and theTypeScript team
——Daniel Rosenwasser 和 TypeScript 团队

本文为公众号“TypeScript社区（QQ 群号 390037547）”原创翻译，转载请注明出处！不然追究法律责任！