我们将40万行代码从Flow迁移到了TypeScript

　　【CSDN 编者按】哪种类型系统将主宰JavaScript的世界？不同时代有不同的答案。本文作者在选择Web生态系统用于构建的产品Factorial时，对比当时Facebook的Flow和微软的TypeScript，综合考虑选择了略胜一筹的Flow。但随着时间的推移，TypeScript开始在该领域展现主导地位。于是决定换框架，来看看他们是怎么做的吧。

　　原文链接：https://labs.factorialhr.com/posts/how-we-migrated-400k-lines-of-code-from-flow-to-typescript

　　本文由 CSDN翻译，转载请注明来源出处。

　　作者 | Ferran Basora

　　译者 | 弯月 责编 | 章雨铭

　　出品 | CSDN（ID：CSDNnews）

　　在构建我们的产品Factorial之际，Web生态系统正在经历一场激战：哪种类型系统将主宰JavaScript的世界。两大主要竞争者分别是来自Facebook的Flow和来自微软的TypeScript。就功能而言，这两大框架似乎并没有太大区别，只不过Flow支持async/await和装饰器等不错的功能，所以略胜一筹。更不用说它与React都出自Facebook之手，因此在当时，它与React配合使用的效果更佳。

　　在Web（无论是前端还是后端）不支持类型检查的时代，将类型系统（无论是哪一种）添加到最小可行产品成为了代码质量和维护方面的及格线。最后，我们还是选择了Flow。

　　随着时间的推移，TypeScript开始在该领域展现出主导地位。TypeScript的发展更快、社区更大、拥有大量的类型库、拥有更好的插件和IDE支持，以及许多其他优势，例如在npm生态系统中的广泛采用，因此许多拥有类型的库都得以公开。

　　另一方面，我们深受Flow检查器无休止的分析和内存泄漏方面的折磨，尽管TypeScript检查器在性能方面的表现也差强人意，但它在配置方面的粒度与各种标志确实非常吸引人。于是，我们决定换框架。

　　迁移的注意事项

　　在迁移方法的初步审查期间，为了确保迁移成功，我们列出了一组必须遵守的约束，其中包括：

　　不能冻结代码。想象一下告诉开发团队：“我们要开始迁移大量的代码了，持续时间还不确定，你可不可以暂停一下手头的工作……”不太现实吧？停止开发会给项目带来太多风险。

　　保留 Git 历史记录。源代码的信息远不止代码本身，还有每一行代码背后的历史记录。如果在代码迁移到过程中，这些历史记录丢失，就太可惜了。

　　在进行最终的迁移时，最好不要干扰现有的拉取请求。我们不希望代码迁移引发大量拉取请求方面的冲突和各种麻烦。

　　不能造成思维模式的混乱。许多教程在介绍JavaScript文件中使用TypeScript的功能时，都采用了渐进式的迁移过程。但是，我们不希望团队在思维模式方面出现混乱，即不知道在某个时间点使用哪种技术，并导致无法判断迁移何时结束。

　　这些约束并非晦涩难懂，但是我们会竭尽所能遵守这些约束，并找出迁移需要面对的长期挑战。

　　
左右为难

　　在开始迁移代码之前，我们首先研究了其他团队，他们也面临着相同的挑战：将庞大的代码库从Flow（或JavaScript）迁移到TypeScript。我们做了很多研究，并在动手迁移代码之前总结了一些经验。

　　在代码迁移的策略方面，我们有两个选择：

　　方法A：将大部分代码库都迁移过去，以尽可能减少思维模式混乱的问题。这就需要渐进式迁移，所以我们选择从没有依赖关系的文件夹开始下手。

　　方法B：创建一个“一次性”脚本来迁移整个代码库。通过这种方法正确迁移代码的难度非常大，因为我们需要将Flow的每一行代码都自动地转换成TypeScript。

　　最后，我们决定混合使用这两种方法（吸取两家之长）。我们发现，代码库中有一大块代码与其他文件之间是解耦的，很适合作为迁移的首个目标，并验证在生产中使用Typescript的想法。令人惊讶的是，我们率先迁移了这部分代码，并成功交付了。我们证明了Flow和TypeScript可以并存。因此，我们对一次性交付其余源代码的信心大增。

　　
另一个困境：工具

　　Ts-migrate：这是我们找到的最出色的工具之一，来自Airbnb，它可以自动迁移JavaScript代码库，同时根据TypeScript语言服务器的输出来决定如何处理不符合规范的地方。但我们没有采用这种方式，因为我们需要将代码从Flow迁移到TypeScript，而不是从JavaScript到TypeScript，二者完全没有可比性。

　　Flow-to-ts：这是我们此次代码迁移采用的主要工具之一，来自可汗学院。该工具是此次迁移的基础，我们对这款工具充满了感激。稍后我们会进一步讨论为何当初选择了它。

　　
开始迁移

　　为了遵守上面提到的首要约束（避免代码冻结），我们想方设法将尽可能多地将安全代码合并到主分支中。所谓“安全代码”指的是将TypeScript的配置文件、输入定义等推送到代码库。

　　另一方面，我们在一个分支中写了一个bash脚本，其中包含了迁移的所有步骤。以下是该脚本中包含的迁移步骤：

　　运行一组自定义的JsCodeShift转换；

　　在Git上，将所有js和jsx文件重命名为ts和tsx；

　　针对上述所有代码运行flow-to-ts转换；

　　运行lint和格式化工具，检查格式；

　　运行tsc验证并查看不符合规范的地方。

　　自定义JsCodeShift转换

　　考虑到上述步骤，我们决定不断迭代，以逐步减少tsc检测出的规范违反的代码。对于所有重复出现的规范违反，我们尝试编写了一些JSCodeShift转换。我们大量使用ASTExplorer作为实验场所，来编写我们的自定义转换。由于我们的代码库是Flow，所以我们决定利用这个先天优势，自动调整与类型相关的代码，以简化flow-to-ts的转换。

　　在这一步中，我们编写了十多个自定义转换，然后同时执行所有转换。

　　module.exports = function (file, api, options) {const fixes = [transformation1,transformation2,transformation3,
return fixes.reduce((src, fix) => {if (typeof src === 'undefined') {return
return fix({ ...file, source: src }, api, options)}, file.source)
Git 重命名

　　根据bash脚本，下一步是文件的重命名。我们使用了git mv，尽可能保持Git历史记录：

　　find $@ -iname "*.js" | while read line; do git mv -- $line ${line%.js}.ts; done;find $@ -iname "*.jsx" | while read line; do git mv -- $line ${line%.jsx}.tsx; done;

　　这一步的工作很简单，很容易被忽略，但从长远来看却非常重要。

　　运行 flow-to-ts

　　在这一步中，脚本需要使用flow-to-ts包执行主要的转换。flow-to-ts是Flow项目的一个核心工具，它理解许多Flow的常见模式，这些模式可以确定地映射到Typescript。它的内部是一个巨大的 JSCodeShift 转换，但有一些预设的配置可以让该工具的使用更容易。

　　Lint和格式化

　　尽管flow-to-ts的底层使用了recast ，而且会尽可能地保留代码原来的格式，但在转换到过程中会新建一些代码。这些代码需要格式化，以匹配我们的内部规则。

　　这一步有点慢，但不可略过。尽可能保持代码原来的格式对于保留Git历史记录至关重要。

　　使用tsc进行验证和审查

　　有了这个脚本，完成迁移到最后一步就是解决其他非重复性的规则违反。老实说，这是最困难的一部分工作，因为我们必须逐一排查并解决。在这个过程中，由于代码库是Flow，所以我们可以不断地将类型修复推送到master分支，同时还不会影响到应用程序的行为。

　　
总结成功的经验

　　我们成功了！我们一次性将40万行代码从Flow迁移到了TypeScript！在这个过程中，我们积累了很多宝贵的经验。

　　保持透明，持续沟通，以获得团队的支持。最糟糕的情况是，在没有取得每一位团队成员支持的情况下，开展大量的工作。我们建议，分享、参与和记录迁移的每一个步骤、里程碑和关键日期。

　　在开始动手迁移代码之前，做好准备。这是一个漫长的过程，需要深入了解代码库。你可能会发现，为了完成最后一步的迁移，前面的有些步骤需要返工。举个例子，我们发现装饰器的使用会影响flow-to-ts的执行。

　　仔细思考迁移后代码的情况，并提出正确的问题。迁移后的所有工具都准备好了吗？开放的拉取请求会影响迁移吗？迁移后是否会出现lint和格式的问题？我们在合并代码之前，就已经解决了这些问题。

　　最好将所有与迁移相关的提交压缩为一个提交。这可以简化部署，如果出现意外情况，也很方便回滚。

　　
今后的打算

　　我们的TypeScript之旅并没有就此结束。事实上，这只是一个开始！在采用该语言几天后，我们决定启用编译器中的strict标志。对我们来说幸运的是，我们可以逐步完成这项工作，因为这些标志可以一个个添加。

　　此外，我们也在考虑其他工具和机会。例如，目前我们使用Webpack来构建应用程序，但我们已经开始考虑esbuild和swc，因为这两个编译器对 TypeScript的支持更好。

　　几个月前，我们也惴惴不安，不知道能否在前端代码库中使用TypeScript。我们分析了利弊，并为此次大规模的代码迁移制定了明确的计划。两周后的今天，我们团队实现了更快的交付，而且还大幅提高了代码质量。这不仅可以减少生产中的错误，而且还可以让客户更满意。

　　如果你也面临相同的困境，希望这篇文章对你有所帮助。