有一种说法是 9102 年做 Node 后台开发还不上 Typescript 不是太懒惰就是太菜了,其实假如你使用 Egg.js, 他们已经对基于 ts 开发做了许多支持,在项目里引入 ts 并没有那么困难,且对减少开发过程中的低级错误非常有帮助。
在这里记录一下个人在 Egg.js 项目里引入 ts 的一些约定,其实都在官方文档、文章和 Github issue 里了。
从 JS 迁移到 TS
web 开发不是瀑布流,定了需求闭门开发几个月上线,往往是基于线上运行的 js 项目,要改造成基于 ts,前提是不能中断服务,初步设想有以下三种方案:
- 逐步替换文件,.js 和 .ts 后缀文件并存,通过 .d.ts 文件来标明类型获取提示;
- 分成 js base 和 ts base 两个项目,逐步替换接口,新接口完成并通过测试后,流量切换到新项目;
- 直接做项目全量文件的 ts 化,利用 any 类型先完成迁移,后期再逐步以【用到了就重构】的原则重构所有代码。
第一种方式在定义 .d.ts 文件时非常繁琐且会有一些坑,如很难推断函数返回类型,且在使用一些 es 原生方法时覆盖类型会有坑;
第二种方式需要实现一种流量切换的方式,如加入 haproxy 中间层,通过 header 或是 path 等方式来识别新老接口流量。碰到的主要问题是在新老项目一个服务往往要改动多个公共文件,很难保持同步,会有矛盾发生;
第三种方式是最后采用的方式,从 js 代码中切出一个新分支,写了脚本批量替换文件后缀,花了大约 2-3 天完成迁移,期间在旧 js 代码中添加的新功能,需要确认在新 js 代码中也实现一遍。
过程中也是发现了一些坑,举例:
- ['dev', 'stage'].includes(item), 若 item 有可能为 undefined,则代码会报错,这里就不像 js 那么灵活
- parseInt 只接受 string 参数,而之前有时为了确保得到的一定是数字,会往这个函数里传入 number 类型参数,ts 对这种情况会报错。值得注意的是,由于 any 类型可赋值给所有类型,所以如果 ts 推断传入参数是 any 类型,parseInt(any) 是不会报错的。这也是为什么有人推荐在 tsconfig.json 中打开 noImplicitAny 选项的原因。保证 parseInt(item) !== NaN 这种逻辑,还是应该手动实现,不能完全依赖于 ts 的判断;
- Object.entries, array.map 等 es 内置方法有自己的类型定义,有可能会导致你传入的参数类型丢失(降级),如 Object.entries 函数原型定义里,`entries<T>(o: { [s: string]: T } | ArrayLike<T>): [string, T][];
entries(o: {}): [string, any][];` 假如传入的参数类型是某种字符串字面量,这里变到 s 之后类型就成了 string
- 在改造过程中难免处于简化需求把 array 类型设为 any[], 这时再 map,里面的参数也会跟着变成 any 类型,想从里面的参数中取值赋值,有时就会发生报错。从快速迁移的目的上来讲,可以灵活使用 any + // 来临时忽略报错。
基于 Egg.js 开发的约定
参考 该文章
编译开发
在本地开发时,使用 egg-bin dev 命令启动应用,egg-bin 自带 ts-node,可以直接运行 ts 代码,无需编译过程;
发布到线上时,egg 官方建议是还是使用 Node + js 原生代码,使用 egg-script start 启动,所以需要将 ts 代码编译成 js 的过程。
在后端开发时可以主动升级 Node 版本,使用一些先进的 es 语法新特性,不像前端为了编译成浏览器普遍能兼容的 es5 代码会使用很多 polyfill 的技巧,所以 ts 代码编译成 js 后其实并没有太难懂(tsconfig.json 里 compilerOptions => target -> es2017)。尽管如此使用编译后的 js 代码还是需要映射回 ts 代码,以便线上报错时能有比较清晰的提示,ts 采用的方案是 sourceMap (tsconfig.json => compilerOptions =>inlineSourceMap -> true)。
关于 sourceMap 的原理可以参考阮一峰的这篇文章。
编译产物位置
egg-bin 在加载文件时,如果识别到同目录下的 .ts 文件和 .js 文件,会优先加载 .js 文件。
真实环境下,为了避免把 .ts .js 文件同时托管在 git 上,造成混乱,最好是引入 ci 层完成编译的工作,这时就可以使用单独的 dist 目录来托管编译后的 js 代码,无需上述 egg-ts-helper 操作,设置 tsconfig.json => compilerOptions => outDirs -> ./dist 即可。
内置对象类型推断
egg 扩展了 koa 的application、context 对象,挂载了 controller、service、model 等对象在上面,然而你自己定义的 controller 文件 ts 无法感知他们和 egg 的关系,所以 egg 提供了 egg-ts-helper 工具来完成来自动生成 .d.ts 文件,放在 typings 目录。参考文章
由于 model 目录并不是 egg 默认约定会使用的目录,只是大多数开发者的一个通识,所以针对 model 目录 egg-ts-helper 并不会主动生成 .d.ts 文件,你需要主动提供 tshelper.js 文件,利用 egg-ts-helper 提供的 api 来 watch model 目录。
启用 egg-ts-helper 的方式很简单,老的方式是 egg-bin dev -r egg-ts-helper/register 新的方式是设置 package.json => egg => declarations -> true
tsconfig.json
- resolveJsonModule => ts 默认无法加载 json 模块,需要开启此选项
- paths => 该选项是为了简化在代码中引用一些模块时,需要注意相对路径的问题,配合 baseUrl 选项即可比较方便的使用一些模块,详情参考文档。实际使用有一些注意事项,参考 egg 官方的提示
发布流程
线上使用 ci 负责编译工作,ci 服务器需要下载全部依赖(包括 dependencies 和 devDependencies),得到编译产物后,再发布到 staging 服务器,staging 服务器只运行 npm install --production, 打包成 docker 镜像再发布
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用
。你还可以使用@
来通知其他用户。