Nest.js 是流行的 node 服務(wù)端框架，最近我注意到它有一個(gè)大的 PR。

這個(gè) PR 涉及到 50 多個(gè)文件，800 多行代碼的改動(dòng)：

同學(xué)們肯定會(huì)覺(jué)得這么多代碼改動(dòng)肯定是大版本升級(jí)無(wú)疑了。

然而，它并沒(méi)有更新版本號(hào)：

可以看到 Nest 從 gulp 切換到了 tsc 編譯，但是版本號(hào)依然是 9.1.2。

為什么這么大的 PR 沒(méi)有改版本號(hào)呢？

看下 PR 的內(nèi)容就知道了：

這個(gè) PR 是從 gulp 切換到了 tsc 的 Project Reference，優(yōu)化了編譯性能，并且啟動(dòng)也更簡(jiǎn)單了。

只是構(gòu)建相關(guān)的優(yōu)化，不更新版本號(hào)也正常。

有的同學(xué)可能會(huì)問(wèn)了，Project Reference 是什么東西？為什么它能提升 tsc 編譯性能呢？

我們先看下之前 Nest 是怎么編譯 nest 源碼的：

通過(guò) gulp 的 build 命令，產(chǎn)物輸出到 node_modules/@nestjs 下。

gulp 記錄了項(xiàng)目中每一個(gè)包的 tsconfig.json：

然后用 tsc 讀取每一個(gè) tsconfig.json 來(lái)編譯 ts 代碼：

這個(gè)流程很容易理解，就是通過(guò) tsc 根據(jù)一個(gè)個(gè)的 tsconfig.json 來(lái)編譯 ts 代碼，輸出到不同目錄，gulp 只是組織這個(gè)流程的。

那現(xiàn)在 tsc 又是怎么編譯的呢？

首先，現(xiàn)在不用 gulp 組織流程了，直接執(zhí)行 tsc，只是加上了 -b，這個(gè)就是開(kāi)啟 project reference 用的：

所謂的 project reference 就是這個(gè)東西：

image.png

也就是 tsconfig 里通過(guò) references 引用其他 project。

如果其他 project 也依賴別的 project 可以再次引用：

編譯的時(shí)候就會(huì)一起編譯。

這樣和單獨(dú)跑 tsc 不是一樣么？有區(qū)別么？

區(qū)別大了去了。

現(xiàn)在執(zhí)行 tsc -b 之后會(huì)在每個(gè) project 下生成這樣一個(gè) tsconfig.build.tsbuildinfo 的文件：

每個(gè) project 都有：

那這個(gè)文件有啥用呢？

看下內(nèi)容就知道了：

它記錄了這個(gè) project 所有編譯的文件名：

還有 hash 的版本號(hào)，是否訪問(wèn)了全局作用域：

這樣再次編譯的時(shí)候有啥不一樣么？

那肯定是編譯過(guò)后的就不用編譯了呀，相當(dāng)于做了一層緩存，每次對(duì)比下改動(dòng)的文件的 hash，如果有變化才去編譯。

不同的 project 是分開(kāi)緩存的，一個(gè) project 變了只要單獨(dú)編譯那個(gè) project 即可，其余的就可以跳過(guò)了。

這樣自然就可以提升編譯性能。

不過(guò)它提升的只是第二次編譯的性能，首次編譯還是要全量編譯的。

這也是為什么 PR 里提到的是更快的 rebuild：

為什么從 gulp 切換到 tsc project reference 我們知道了。那新版的 nest 如何調(diào)試呢？

我們直接用 nest 項(xiàng)目自帶的案例調(diào)試就行。

nest 提供了 sample 目錄，下面有很多案例項(xiàng)目：

我們新建一個(gè) .vscode/launch.josn 的調(diào)試配置文件：

image.png

新增這樣的調(diào)試配置：

{
  "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"
}

這個(gè)配置很容易看明白，就是在 01-cats-app 這個(gè)目錄下執(zhí)行 npm run start。

那 console 指定為 integratedTerminal 是什么意思呢？

跑一下就知道了：

跑起服務(wù)來(lái)，打個(gè)斷點(diǎn)，訪問(wèn) localhost:3000/cats，你會(huì)發(fā)現(xiàn)日志是打印在 debug console 的：

沒(méi)有顏色，這自然用的不習(xí)慣。

指定 console 為 integratedTerminal，再重新調(diào)試：

現(xiàn)在日志就打印在 terminal 了，是不是順眼多了？

這是調(diào)試 nest 項(xiàng)目的方式。

那怎么調(diào)試 nest 源碼呢？

現(xiàn)在調(diào)用棧里的 nest 代碼都是編譯過(guò)后的：

想調(diào)試源碼就要有 sourcemap。

默認(rèn) nest 編譯不產(chǎn)生 sourcemap，我們要改下編譯配置：

改下 packages/tsconfig.build.json，加上這兩個(gè)配置就可以了。

sourceMap 為 true 就是生成 sourcemap 的意思，inlineSources 是在 sources 里保存源碼，默認(rèn)生成的 sorucemap 是不包含源碼的。

執(zhí)行 npm run build。

你就會(huì)發(fā)現(xiàn)生成了 sorucemap：

但是 node_modules/@nestjs 下還是沒(méi)有 sourcemap，這是因?yàn)檫€少了一步：

nest 的 build 命令有個(gè)后置命令：

每次 build 完就會(huì)自動(dòng)把這些文件復(fù)制到 node_modules/@nestjs 下：

默認(rèn)沒(méi)有編譯出 sourcemap，自然也就沒(méi)有 move 這部分文件。

補(bǔ)上這塊，再次執(zhí)行 npm run build：

然后去 node_modules 下看一眼：

現(xiàn)在就有 sourcemap 了，完美！

然后再跑下 nest 項(xiàng)目的調(diào)試：

咋還不是源碼呢？

這確實(shí)比較坑，因?yàn)橛袀€(gè)默認(rèn)配置，禁掉了 node_modules 下的 sourcemap 查找：

去掉即可：

然后重新跑調(diào)試：

這時(shí)候你就會(huì)發(fā)現(xiàn)調(diào)試的是 nest 的 ts 源碼了！

總結(jié)

nest 最近通過(guò)一個(gè)大 PR 把構(gòu)建方式從 gulp + tsc 切換到了 tsc -b 也就是 project reference 的方式，這樣能極大的提升 tsc 編譯性能。

原理就是 project reference 的模式會(huì)生成一個(gè)緩存文件記錄著每個(gè) project 編譯了哪些文件，hash 是啥，這樣再次編譯就可以跳過(guò)沒(méi)有更新的文件。

新版 nest 源碼的調(diào)試也同樣需要生成 sourcemap，修改下編譯配置，生成 sourcemap 的代碼即可（只不過(guò)要注意 VSCode Node Debugger 的一個(gè)坑，默認(rèn)不查找 node_modules下的 sourcemap）。

然后就可以愉快的調(diào)試 nest 的 ts 源碼了！

nest 這么大的項(xiàng)目都用了 tsc project reference 來(lái)優(yōu)化編譯性能，那平時(shí)我們的項(xiàng)目自然也可以用 project reference 來(lái)優(yōu)化，ts 編譯性能優(yōu)化的時(shí)候不妨往這方面考慮一下。