Slack团队切换至TypeScript，简化大型JS代码库管理

Posted 2021-04-25 前端之巅

作者｜Sergio De Simone

译者｜大愚若智

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

为了简化大型JavaScript代码库的管理工作，在放弃使用进行函数签名的记录，以及相关用途的描述后，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对声明文件的处理方法。

相关链接

本文英文原文：

Felix Rieseberg 所撰写文章：

今日荐文

React 15.5带来重大修改，为开发者留充足时间适应版本16

---

视野拓展

InfoQ主办的移动和前端开发领域的精品大会【GMTC 2017】将于6月9～10日在北京举行，作为首届以“大前端”为主题的大会，GMTC涉及移动、前端、跨平台、AI应用等多个技术领域，帮助你方方面面提高技术水平。扫描下图二维码或戳阅读原文，前往官网了解详细信息！

前端之巅