Slack 从 JavaScript 切换至 TypeScript

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 对声明文件的处理方法。

阅读英文原文： Moving from JavaScript to TypeScript at Slack