Nest.js 这么大的项目是怎么优化 ts 编译性能的？ - 哈喽比特

503次阅读 | 发布于1年以前

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：

然后用 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 的：

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