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, 如有侵权, 请联系作者删除)
网友评论