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