前言
在日常迭代工作中相对于写代码，我们往往花费在读代码的时间上会更多。而代码会随着时间的推移和业务的累积而腐朽了，保持代码的“鲜活”能有效提高开发人员的效率，而js向ts的迁移可以有效的将代码逻辑层面的错误在编译阶段就暴露出来有效预防线上出现 XXX is undefiend 这类低级错误。
我司的人员流动是我这辈子见过最大的地方，随着技术方案更新，后面接手的同事未及时对代码进行更换，也往往不敢删改大多开发，希望我在职期间我负责的代码因为我变得更有可读性和可维护性，拒绝堆积木式的开发。
青铜ts迁移方式
遇到一个js文件改一个，从修改文件扩展名.js|jsx到.ts｜tsx
白银ts迁移方式
此处推荐 我目前用的插件ts-migrate
-
官方 www.npmjs.com/package/ts-… （这个真的要认真看）
-
安装：yarn add --dev ts-migrate （首推yarn 安装 npm我这不晓得为什么一直报404 找不到资源）
-
文件扩展名一键修改：
npx ts-migrate-full ./ --sources="app/components"-
我是小心翼翼地 一个模块一个模块的迁移（大佬 或者项目没那么复杂的完全可以一次性全局替换）
-
对比官方绝对路径 ，个人感觉 自己上面那种cd进入文件夹，相对路径指向当前文件 的方法更简便
-
- 没报错的话就一路回车 continue
4. 把自动生成的tsconfig.json 删除，因为我们的项目本身就是混合迁移的 外层已经有了tsconfig.json
5.是不是很easy，而且 修改完 仍然会保留原作者的提交记录 相比 自己一个文件一个文件的修改，那样修改后就全成了自己的代码 也不好追溯原责任人，那只能背锅
6. 看起来
ts-migrate并没有那么的智能（有可能我的解锁方式也不对），but 至少 我们不用手动的去修改 每一个文件的扩展名。跟我的步骤走到这里，还会很多类型错误导致服务起不来；真正的体力活开始了
- 我的方式：yarn start 启服务，根据进程错误提示修改，一个一个 手动去新增类型
- 其他小伙伴的方式：直接从模块主入口开始 依次向下新增或者修改类型
- 最后还是测试小伙伴承担了所有回归测试的工作
小结
ts迁移真的没有 技术能力的考验 但很磨性子，考验细心，尤其是遇到那种多层嵌套的组件，组件里又是直接this.prop传给它的子组件，都是js文件，也不指望 有props的类型定义。 整个传递给 子组件的，连续this.prop传递了4层5层。当场血压会飙高
目前我们还没有遇到 更有效的ts迁移方式，欢迎看到此篇小结的同学留言别的迁移方式或者工具
