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贡献指南和微软开源行为准则。
查看英文原文:https://www.infoq.com/news/2019/02/typescript-3-3-release