TypeScript 3.3 发布：改进了联合类型调用和构建时间

TypeScript 团队继续以双月发布节奏发布了 TypeScript 3.3，这一版本改进了调用联合类型的行为以及复合项目增量文件的监听性能。该团队还宣布了未来六个月的TypeScript 路线图。

TypeScript 3.0 添加了对复合项目的支持，可以将大型项目分成较小的项目，改进–build 模式下的构建时间，而且只重新编译必要的项目和依赖项，以此来优化项目间的构建。同时还添加了一个项目内增量构建 API，用于升级发生变更或者包含可能会影响类型检查的依赖项的文件。

在 3.0 发布之后，有关在复合项目中使用–watch 标志的性能问题的抱怨有所添加。复合项目并没有利用项目内增量构建功能，而是进行完整的项目构建。

现在，在 TypeScript 3.3 的–build 模式下使用–watch 标志可以利用增量文件监听功能明显改善构建时间，可以将构建时间平均缩短 50-75％。

TypeScript 支持联合类型，开发人员可以访问联合成员所共有的属性。在调用类型时，假如每个类型没有具备相同参数的调用签名，就很难为返回类型定义联合。

在 TypeScript 3.3 中，每个联合成员的参数组合在一起形成新的签名。只有当联合中有一个类型具备多个重载并且有一个类型具备通用签名时，才会应用新的行为。TypeScript 团队在 TypeScript 3.3 中增加这一新添加功能，作为改进方案的第一步，并可能在将来的版本中做出进一步的改进。

与最近发布的版本相比，TypeScript 3.3 只提供了相对适度的新功能，主要是由于双月发布节奏恰好碰上了寒假，但也可能是由于 TypeScript 团队在六个月路线图中提及的内容，线路图重申了除了为语言增加更多功能之外的工作：

• 将类型带给所有开发者；
• 借助强大的工具提高生产力；
• 可访问性和客户体验；
• 社区参加；
• 基础设备和工程系统；

TypeScript 团队依然专注于增加新的 ECMAScript 功能和改进 TypeScript，但它已达到了肯定程度的稳固性。

在过去的一年中，TypeScript 在 JavaScript 生态系统得到了大规模采用，包括 Vue.js 的下一个版本、Jest和Storybook将迁移到 TypeScript。很多开发人员和项目正在从 JavaScript 迁移到 TypeScript，而有少量则从 Flow 迁移到 TypeScript。

来自 Hootsuite 的软件工程经理 Ovidiu Bute 解释了他们为什么要迁移到 TypeScript：

我们还观察了与这两个项目相关的社区。Flow 由 Facebook 以一种非常封闭的方式驱动，开发素来都不透明，也没有提供公开的路线图，除 Facebook 以外很少有人参加这个项目。相比之下，TypeScript 在几年前迁移到 GitHub 之后就开始拥抱开源。他们保持最新的路线图，接受外部贡献，并与社区保持非常密切的关系。

Babel 原始作者和 Facebook 工程师 Sebastian McKenzie 在答复客户提出的有关 Flow 的功能时解释道：

老实说，我建议现在切换到 TypeScript，由于 Flow 的开源之旅不被重视。

Flow 团队已经开始着手处理这些问题，可以在这里看到最近的进展和 2019 年的计划。Facebook 软件工程师 Avik Chaudhuri 阐述了从 Flow 到 TypeScript 的迁移：

最近，少量最初由 Facebook 创立的开源项目计划使用 TypeScript 重写。在 Facebook，我们非常重视各个团队在创立路线图以及在他们尽最大努力构建产品时的独立性。少量项目决定切换到 TypeScript，有了外部贡献者，开发可能会更容易，我们尊重他们的决定。

少量现有框架（如 Angular、Dojo 和Ionic）已经使用了 TypeScript，少量框架则计划切换到 TypeScript，或者者至少提供了类型定义或者 CLI 工具，由此可见，一大部分 JavaScript 开发人员现在正在采用 TypeScript。

TypeScript 是基于 Apache 2 许可发行的开源软件。开发人员可以通过TypeScript GitHub 项目参加贡献和提供反馈，并遵守TypeScript 贡献指南和微软开源行为原则。

(本文章转载自infoq, 如有侵权, 请联络作者删除)