Nest.js 这么大的项目是怎么优化 ts 编译性能的?

13,119 阅读5分钟

Nest.js 是流行的 node 服务端框架,最近我注意到它有一个大的 PR

这个 PR 涉及到 50 多个文件,800 多行代码的改动:

同学们肯定会觉得这么多代码改动肯定是大版本升级无疑了。

然而,它并没有更新版本号:

可以看到 Nest 从 gulp 切换到了 tsc 编译,但是版本号依然是 9.1.2。

为什么这么大的 PR 没有改版本号呢?

看下 PR 的内容就知道了:

这个 PR 是从 gulp 切换到了 tsc 的 Project Reference,优化了编译性能,并且启动也更简单了。

只是构建相关的优化,不更新版本号也正常。

有的同学可能会问了,Project Reference 是什么东西?为什么它能提升 tsc 编译性能呢?

我们先看下之前 Nest 是怎么编译 nest 源码的:

通过 gulp 的 build 命令,产物输出到 node_modules/@nestjs 下。

gulp 记录了项目中每一个包的 tsconfig.json:

i

然后用 tsc 读取每一个 tsconfig.json 来编译 ts 代码:

这个流程很容易理解,就是通过 tsc 根据一个个的 tsconfig.json 来编译 ts 代码,输出到不同目录,gulp 只是组织这个流程的。

那现在 tsc 又是怎么编译的呢?

首先,现在不用 gulp 组织流程了,直接执行 tsc,只是加上了 -b,这个就是开启 project reference 用的:

所谓的 project reference 就是这个东西:

image.png

也就是 tsconfig 里通过 references 引用其他 project。

如果其他 project 也依赖别的 project 可以再次引用:

编译的时候就会一起编译。

这样和单独跑 tsc 不是一样么?有区别么?

区别大了去了。

现在执行 tsc -b 之后会在每个 project 下生成这样一个 tsconfig.build.tsbuildinfo 的文件:

每个 project 都有:

那这个文件有啥用呢?

看下内容就知道了:

它记录了这个 project 所有编译的文件名:

还有 hash 的版本号,是否访问了全局作用域:

这样再次编译的时候有啥不一样么?

那肯定是编译过后的就不用编译了呀,相当于做了一层缓存,每次对比下改动的文件的 hash,如果有变化才去编译。

不同的 project 是分开缓存的,一个 project 变了只要单独编译那个 project 即可,其余的就可以跳过了。

这样自然就可以提升编译性能。

不过它提升的只是第二次编译的性能,首次编译还是要全量编译的。

这也是为什么 PR 里提到的是更快的 rebuild:

为什么从 gulp 切换到 tsc project reference 我们知道了。那新版的 nest 如何调试呢?

我们直接用 nest 项目自带的案例调试就行。

nest 提供了 sample 目录,下面有很多案例项目:

我们新建一个 .vscode/launch.josn 的调试配置文件:

image.png

新增这样的调试配置:

{
  "name": "Launch via NPM",
  "request": "launch",
  "runtimeArgs": ["run-script", "start"],
  "runtimeExecutable": "npm",
  "console": "integratedTerminal",
  "cwd": "${workspaceFolder}/sample/01-cats-app/",
  "skipFiles": ["<node_internals>/**"],
  "type": "node"
}

这个配置很容易看明白,就是在 01-cats-app 这个目录下执行 npm run start。

那 console 指定为 integratedTerminal 是什么意思呢?

跑一下就知道了:

跑起服务来,打个断点,访问 localhost:3000/cats,你会发现日志是打印在 debug console 的:

没有颜色,这自然用的不习惯。

指定 console 为 integratedTerminal,再重新调试:

现在日志就打印在 terminal 了,是不是顺眼多了?

这是调试 nest 项目的方式。

那怎么调试 nest 源码呢?

现在调用栈里的 nest 代码都是编译过后的:

想调试源码就要有 sourcemap。

默认 nest 编译不产生 sourcemap,我们要改下编译配置:

改下 packages/tsconfig.build.json,加上这两个配置就可以了。

sourceMap 为 true 就是生成 sourcemap 的意思,inlineSources 是在 sources 里保存源码,默认生成的 sorucemap 是不包含源码的。

执行 npm run build。

你就会发现生成了 sorucemap:

但是 node_modules/@nestjs 下还是没有 sourcemap,这是因为还少了一步:

nest 的 build 命令有个后置命令:

每次 build 完就会自动把这些文件复制到 node_modules/@nestjs 下:

默认没有编译出 sourcemap,自然也就没有 move 这部分文件。

补上这块,再次执行 npm run build:

然后去 node_modules 下看一眼:

现在就有 sourcemap 了,完美!

然后再跑下 nest 项目的调试:

咋还不是源码呢?

这确实比较坑,因为有个默认配置,禁掉了 node_modules 下的 sourcemap 查找:

去掉即可:

然后重新跑调试:

这时候你就会发现调试的是 nest 的 ts 源码了!

总结

nest 最近通过一个大 PR 把构建方式从 gulp + tsc 切换到了 tsc -b 也就是 project reference 的方式,这样能极大的提升 tsc 编译性能。

原理就是 project reference 的模式会生成一个缓存文件记录着每个 project 编译了哪些文件,hash 是啥,这样再次编译就可以跳过没有更新的文件。

新版 nest 源码的调试也同样需要生成 sourcemap,修改下编译配置,生成 sourcemap 的代码即可,只不过要注意 VSCode Node Debugger 的一个坑,默认不查找 node_modules下的 sourcemap。

然后就可以愉快的调试 nest 的 ts 源码了!

nest 这么大的项目都用了 tsc project reference 来优化编译性能,那平时我们的项目自然也可以用 project reference 来优化,ts 编译性能优化的时候不妨往这方面考虑一下。