Slack从JavaScript切换至TypeScript

开发 TypeScript JavaScript 跨平台 Web开发

摘要：

Slack桌面端工程师Felix Rieseberg撰文介绍了Slack从JavaScript切换至TypeScript充满挑战，但也获得了巨大收益的过程。InfoQ采访了他。

正文：

Slack桌面端工程师Felix Rieseberg撰文介绍了Slack从JavaScript切换至TypeScript充满挑战，但也获得了巨大收益的过程。

为了简化大型JavaScript代码库的管理工作，在放弃使用JSDoc进行函数签名的记录，以及相关用途的描述后，Slack团队决定切换至TypeScript。Rieseberg专门提到，对于现有代码库，很难应用JSON的方法，因为这需要对代码的修改制定严格的约束，但实际上通常可能根本无法轻松地了解预期的类型到底是什么，例如一个Ppromise所要解决的到底是什么问题。

Slack团队选择TypeScript的原因之一在于，TypeScript是JavaScript的超集，因此无须更改现有代码即可使用，并能在采用后逐渐启用其代码分析功能，包括很多流行的软件包中提供的类型定义。随着时间的流逝，他们稍后还可以启用高级编译器选项，例如--noImplicitAny，借此防止编译器就any类型进行推断。Rieseberg说他们花了大约六个月的时间为大部分桌面应用的代码添加注解，在这个过程中，编译器发现了很多Bug，并且他们通过诸如自动补全等高级编辑功能大幅加快了开发速度。

InfoQ就这一过程采访了Rieseberg。

您提到才用了循序渐进的方法来启用TypeScript的编译器选项。能否详细说说哪些选项可以在一开始就启用，哪些选项需要在对原有代码进行更多调整之后才能启用？

我认为，any类型是将我们的代码库迁移至TypeScript最强有力的理由之一。该类型可以让我们循序渐进地将any声明稳步替换为更具体的类型和接口。随着使用类型数量的增加，我们迟早会从这种交集与合并的类型所提供的抽象中获益，而这些问题原本是新接触类型系统的开发者最头疼的。在我个人看来，循序渐进地采用TypeScript，这种方法的可行性主要源自它可以接纳现有的JavaScript。TypeScript会试图理解你的代码，并尽可能为你的开发工作提供支持，但就算你没时间将自己的整个代码库一次性移植完成，TypeScript也能让人受益匪浅。

从一种动态的类型切换至一种严格类型的语言，通常可以借机重新设计某些东西。Slack遇到过这种情况吗？

我们向着TypeScript的转换主要是由开发者OJ Kwon负责的，他在加入团队后很快就开始进行了。他发现这一过程中有很多机会可以让我们完善现有代码库。尤其是移植到TypeScript的过程可以帮助我们更好地理解架构内部的数据流动，但从更大范围来说，回顾现有代码始终是一种重新思考所采取的具体方法的好机会。

从语言的层面上来说，TypeScript的哪些功能对于你们构建表达式类型系统最有帮助？

我最喜欢声明合并（Declaration merging），这个功能可以让我们重用现有类型和声明，借此表达我们所要实现的目标。此外虽然关注度略低，但我们的代码库中还大量用到了字符串字面量（String literal）类型。

您刚才强调说，TypeScript最大的优势之一在于它是JavaScript的超集。从另一方面来看，这也意味着无法完全确信你从应用的纯JavaScript层所获得的任何东西。对此您是怎么看的？这是否会造成什么问题？

有必要指出一点，围绕TypeScript还有一个名为Salsa的项目，这是一种开发服务器，可以在使用JavaScript时提供类似于TypeScript的体验。正是该项目的引擎帮助Visual Studio Code理解JavaScript。开发过程中我们配合使用了TypeScript、声明文件，以及Salsa，结果还不错。我个人很喜欢TypeScript对声明文件的处理方法。

作者：Sergio De Simone，阅读英文原文：Moving from JavaScript to TypeScript at Slack