将 30 万行代码从 Flow 迁移到 TypeScript 是一种怎样的体验？

2019年7月6日 284点热度 0人点赞 0条评论

作者 | Roger Goldfinger

译者 | 弯月

责编 | 伍杏玲

出品 | CSDN（ID：CSDNnews）

【CSDN 编者按】本文作者在当前正在使用 Flow 下，想一次性切换到TypeScript，涉及30万行代码，他们迁移的过程值得我们借鉴：先合并TypeScript工具，再反复进行练习，成功在12分钟内成功通过CI流程，并最后修复错误。

我们公司一直致力于改善开发人员的工作体验。在使用Flow度过了两年愉快的开发时光后，最近我们决定转而采用TypeScript，因为TypeScript有良好的社区支持、好的编辑体验、支持的类型也更多。

于是，我们决定一次性把Flow转成TypeScript。

我们使用自动转换工具迁移了2,700个Javascript文件，并在12分钟内成功通过CI流程，接下来我们立刻就能享受新语言带来的优势了。与逐步迁移相比，（这样做）我们省却了大量的操作复杂性，并最大限度地减轻了给工程团队带来的负担和影响。在经过了一周的TypeScript学习后，软件工程师们再次重回岗位，开始了更为迅速地开发作业。

为何做出这种改变？

在过去的两年中，我们一直在使用Flow来处理我们Javascript代码中的类型。我们有40名工程师负责开发Web代码，良好的类型系统可以确保代码的正确性、加快新来工程师的适应速度，且有助于安全的重构。当时，Flow是一个正确的选择，逐步采用支持意味着我们可以慢慢适应。

最近随着TypeScript的崛起，越来越多的人选择TypeScript，我们也仔细研究了我们使用的Flow。一直以来我们都知道，Flow与编辑器的集成有时非常缓慢，而且应用程序的核心部分（比如Redux状态和组件props）并没有添加有意义的类型，部分原因是Flow对redux和reselect的typedef支持有问题。由于相应的Flow类型库的维护者已经很长时间没有更新了，所以我们也担心Flow的未来。

在开始接触TypeScript后，我们惊人地发现VSCode对该编辑器的支持非常好，而且还有很多非常有帮助的错误消息，此外社区的支持也很给力。再加上其他流行的代码库和项目，让我们欣喜若狂，我们越发肯定这是正确的方向。

实际的代码迁移过程

迁移近30万行的代码，这个工作量似乎超出了手动的承受范围，所以我们决定一次性转换整个代码库，使用babel插件完成语法的修改，再通过一个脚本重命名文件。

我们考虑过逐步迁移，一次将一个文件迁移到TypeScript中。为了在迁移期间保留跨语言的类型，我们可以输出两种语言的定义文件，然后生成这些定义文件到另一种语言的转换。最终，我们担心这种方法过于复杂，工程师必须掌握代码库中两种不同的语言，并且迁移可能需要很长时间，这个过程通常还会增加现有工作的复杂性。

为了准备大规模迁移，首先我们合并了TypeScript工具，例如配置Babel和设置ESLint。我们一遍又一遍地反复练习迁移的过程，练习快速地可靠地让转换后的代码库通过CI流程，并在运行手册上记录了这个过程。

到最后的时候，我们能够在12分钟内完成所有的代码迁移，并执行完所有的手动步骤通过CI流程。这确保我们能够最大限度地减少对工程师现有工作的干扰，并确保我们有时间解决意外发生的问题。

最后，在我们约定好的那一天，我们快速冻结了代码库，然后执行了手册上的所有步骤，对这些变更进行了一些手动测试，并将代码合并到了生产中。

修复错误

当然，迁移到TypeScript中的代码库存在很多错误（大约有6千多个），我们决定暂且通过注释// @ ts-ignore忽略这些错误，先通过CI流程再说。毕竟，Flow的类型覆盖没有捕获到这些错误。只有忽略这些错误，我们才能够一次性地完成迁移，而无需在修复错误的过程中冻结整个代码库。

我们编写了一个脚本，自动将// @ ts-ignore注释插入到我们的大多数代码中，同时保证这些忽略掉的都是因为JSX过于复杂。于是，我们的JSX中残留了大约1,400个错误，在接下来的一周里，我们每个人都动手修复这些错误。这为我们每个人提供了一次很好的学习TypeScript的机会，在修复剩余错误的过程中，我们熟悉了类型系统和最佳实践。