Nest.js 這么大的項目是怎么優(yōu)化 ts 編譯性能的？
Nest.js 是流行的 node 服務端框架，最近我注意到它有一個大的 PR。
這個 PR 涉及到 50 多個文件，800 多行代碼的改動：
同學們肯定會覺得這么多代碼改動肯定是大版本升級無疑了。
然而，它并沒有更新版本號：
可以看到 Nest 從 gulp 切換到了 tsc 編譯，但是版本號依然是 9.1.2。
為什么這么大的 PR 沒有改版本號呢？
看下 PR 的內(nèi)容就知道了：
這個 PR 是從 gulp 切換到了 tsc 的 Project Reference，優(yōu)化了編譯性能，并且啟動也更簡單了。
只是構(gòu)建相關(guān)的優(yōu)化，不更新版本號也正常。
有的同學可能會問了，Project Reference 是什么東西？為什么它能提升 tsc 編譯性能呢？
我們先看下之前 Nest 是怎么編譯 nest 源碼的：
通過 gulp 的 build 命令，產(chǎn)物輸出到 node_modules/@nestjs 下。
gulp 記錄了項目中每一個包的 tsconfig.json：
然后用 tsc 讀取每一個 tsconfig.json 來編譯 ts 代碼：
這個流程很容易理解，就是通過 tsc 根據(jù)一個個的 tsconfig.json 來編譯 ts 代碼，輸出到不同目錄，gulp 只是組織這個流程的。
那現(xiàn)在 tsc 又是怎么編譯的呢？
首先，現(xiàn)在不用 gulp 組織流程了，直接執(zhí)行 tsc，只是加上了 -b，這個就是開啟 project reference 用的：
所謂的 project reference 就是這個東西：
image.png
也就是 tsconfig 里通過 references 引用其他 project。
如果其他 project 也依賴別的 project 可以再次引用：
編譯的時候就會一起編譯。
這樣和單獨跑 tsc 不是一樣么？有區(qū)別么？
區(qū)別大了去了。
現(xiàn)在執(zhí)行 tsc -b 之后會在每個 project 下生成這樣一個 tsconfig.build.tsbuildinfo 的文件：
每個 project 都有：
那這個文件有啥用呢？
看下內(nèi)容就知道了：
它記錄了這個 project 所有編譯的文件名：
還有 hash 的版本號，是否訪問了全局作用域：
這樣再次編譯的時候有啥不一樣么？
那肯定是編譯過后的就不用編譯了呀，相當于做了一層緩存，每次對比下改動的文件的 hash，如果有變化才去編譯。
不同的 project 是分開緩存的，一個 project 變了只要單獨編譯那個 project 即可，其余的就可以跳過了。
這樣自然就可以提升編譯性能。
不過它提升的只是第二次編譯的性能，首次編譯還是要全量編譯的。
這也是為什么 PR 里提到的是更快的 rebuild：
為什么從 gulp 切換到 tsc project reference 我們知道了。那新版的 nest 如何調(diào)試呢？
我們直接用 nest 項目自帶的案例調(diào)試就行。
nest 提供了 sample 目錄，下面有很多案例項目：
我們新建一個 .vscode/launch.josn 的調(diào)試配置文件：
image.png
新增這樣的調(diào)試配置：
這個配置很容易看明白，就是在 01-cats-app 這個目錄下執(zhí)行 npm run start。
那 console 指定為 integratedTerminal 是什么意思呢？
跑一下就知道了：
跑起服務來，打個斷點，訪問 localhost:3000/cats，你會發(fā)現(xiàn)日志是打印在 debug console 的：
沒有顏色，這自然用的不習慣。
指定 console 為 integratedTerminal，再重新調(diào)試：
現(xiàn)在日志就打印在 terminal 了，是不是順眼多了？
這是調(diào)試 nest 項目的方式。
那怎么調(diào)試 nest 源碼呢？
現(xiàn)在調(diào)用棧里的 nest 代碼都是編譯過后的：
想調(diào)試源碼就要有 sourcemap。
默認 nest 編譯不產(chǎn)生 sourcemap，我們要改下編譯配置：
改下 packages/tsconfig.build.json，加上這兩個配置就可以了。
sourceMap 為 true 就是生成 sourcemap 的意思，inlineSources 是在 sources 里保存源碼，默認生成的 sorucemap 是不包含源碼的。
執(zhí)行 npm run build。
你就會發(fā)現(xiàn)生成了 sorucemap：
但是 node_modules/@nestjs 下還是沒有 sourcemap，這是因為還少了一步：
nest 的 build 命令有個后置命令：
每次 build 完就會自動把這些文件復制到 node_modules/@nestjs 下：
默認沒有編譯出 sourcemap，自然也就沒有 move 這部分文件。
補上這塊，再次執(zhí)行 npm run build：
然后去 node_modules 下看一眼：
現(xiàn)在就有 sourcemap 了，完美！
然后再跑下 nest 項目的調(diào)試：
咋還不是源碼呢？
這確實比較坑，因為有個默認配置，禁掉了 node_modules 下的 sourcemap 查找：
去掉即可：
然后重新跑調(diào)試：
這時候你就會發(fā)現(xiàn)調(diào)試的是 nest 的 ts 源碼了！
總結(jié)
nest 最近通過一個大 PR 把構(gòu)建方式從 gulp + tsc 切換到了 tsc -b 也就是 project reference 的方式，這樣能極大的提升 tsc 編譯性能。
原理就是 project reference 的模式會生成一個緩存文件記錄著每個 project 編譯了哪些文件，hash 是啥，這樣再次編譯就可以跳過沒有更新的文件。
新版 nest 源碼的調(diào)試也同樣需要生成 sourcemap，修改下編譯配置，生成 sourcemap 的代碼即可（只不過要注意 VSCode Node Debugger 的一個坑，默認不查找 node_modules下的 sourcemap）。
然后就可以愉快的調(diào)試 nest 的 ts 源碼了！
nest 這么大的項目都用了 tsc project reference 來優(yōu)化編譯性能，那平時我們的項目自然也可以用 project reference 來優(yōu)化，ts 編譯性能優(yōu)化的時候不妨往這方面考慮一下。
