前言
在虾皮，我们组主要负责维护一个pc端的管理后台项目，以及一个手机app。其中手机app用的是原生 + ReactNative(RN) 实现，我们前端组负责维护其中的RN部分。
这是个从越南开发团队交接过来的项目，之前是一个ios程序员写的RN，加之越南那边程序员的水平可能比国内稍差一些，因此交接过来的RN项目大概情况如下
- 项目是ts和js混合编译
- 代码不规范，会有一些上千行的文件，并且代码风格混乱，阅读成本较高
- 有很多不必要但又没有删除的文件
- 目录命名不规范，难以判断需求涉及的页面文件在哪个目录下
交接了半年后我们组终于空出了排期，对把项目改造成纯ts的，并且顺便优化一些问题。
删除无用的代码文件
这是首要的事情，因为无用的代码文件真的很多，如果不删，后面的工作需要多处理很多不必要的问题。但是有一个非常巨大的问题，就是我们不晓得哪些文件是无用的！如果误删了有用的代码，就会引发线上事故。
然后我做了几个事情
- 同时拉取两份RN项目的代码，其中一份删除全部业务代码，保留了代码的叫项目一，删掉代码的叫项目二。
- 找客户端同事要了一份从客户端跳转RN的页面列表，然后深度遍历项目一里这些页面文件，就能筛选出全部有用的页面，把有用的页面文件拷贝到项目二去。
- 在项目二中寻找对路由文件的调用，找到全部从RN页跳转到RN页的页面列表，再次深度遍历并拷贝一次。
- 自测和找测试同事测试
大概的思路就是先找到全部入口文件，然后深度遍历，找到入口文件依赖的全部文件，这样就知道了哪些文件是有用的。为了避免误删，通过自测和测试同事全量回归，避免出现误删的情况
后来统计了一下，删掉了一百多个文件，一共两万八千行代码。
这个故事告诉我们，项目里千万不要留不用的代码
.js文件后缀改成.ts
由于文件太多了，一个一个改是不可能的，于是写了个shell脚本自动修改文件后缀。
但是过程中遇到一个问题，就是之前的开发经常在js文件里使用jsx变量，导致js文件升级成ts文件之后，会报jsx的错误，需要手动把这些文件后缀改为tsx，这个没有想到自动化解决的办法，手动改了好久。
在业务代码目录下运行下面这个脚本，会把js文件后缀变成ts，把jsx文件后缀变成tsx，试用记得要另外拉分支哦
js2ts()
{
echo "当前目录: $1" >> "./rename.txt"
for file in `ls $1`;
do
if test -f $file
then
pathFile="$file"
echo "pathFile: $pathFile \n" >> "./rename.txt"
if test ${pathFile##*.} == 'js'
then
echo "after: ${pathFile%.js}.ts \n" >> "./rename.txt"
mv "$pathFile" "${pathFile%.js}.ts"
elif test ${pathFile##*.} == 'jsx'
then
echo "after: ${pathFile%.jsx}.tsx \n" >> "./rename.txt"
mv "$pathFile" "${pathFile%.jsx}.tsx"
fi
else
js2ts "$1/$file"
fi
done
}
js2ts .;
解决ts文件报错
这里我们主要是先运行项目，拿到全部的报错类型和报错数量。具体做法是npm run start >> ./log.txt把全部输出都打到txt里面去。
对于报错数小于20的，我们全部都手动修复。
对于报错数大于20的，在eslint里配置，忽略掉报错的问题，后面再找时间统一的修改。
调整目录结构
这里先移动代码文件，然后主要是通过vscode的全局搜索和全局替换，把路径名修改为新的路径名，并且通过babel配置路径别名，实现目录结构的调整。
统一代码风格
主要就是业内常用的eslint和prettier，这两个的确会给不熟悉的人带来一些不方便，但是在团队合作里，统一的规范和风格能降低阅读成本，提高团队合作效率，所以还是非常必要的。
综上所述，上面就是我们升级ts的全部工作。但是后来发现，爱彼迎对于升级ts有一套流水线式的工具，可以一键完成ts的升级，这个工具叫做ts-migrate，我有一篇文章就是介绍ts-migrate的，感兴趣的朋友可以去看下。
