建站
咨詢
售后
建站咨詢
新聞中心
Nest.js 是流行的 node 服務(wù)端框架，最近我注意到它有一個(gè)大的 PR。
創(chuàng)新互聯(lián)建站堅(jiān)持“要么做到，要么別承諾”的工作理念，服務(wù)領(lǐng)域包括：成都網(wǎng)站制作、成都做網(wǎng)站、外貿(mào)營(yíng)銷網(wǎng)站建設(shè)、企業(yè)官網(wǎng)、英文網(wǎng)站、手機(jī)端網(wǎng)站、網(wǎng)站推廣等服務(wù)，滿足客戶于互聯(lián)網(wǎng)時(shí)代的柴桑網(wǎng)站設(shè)計(jì)、移動(dòng)媒體設(shè)計(jì)的需求，幫助企業(yè)找到有效的互聯(lián)網(wǎng)解決方案。努力成為您成熟可靠的網(wǎng)絡(luò)建設(shè)合作伙伴！
這個(gè) PR 涉及到 50 多個(gè)文件，800 多行代碼的改動(dòng)：
同學(xué)們肯定會(huì)覺得這么多代碼改動(dòng)肯定是大版本升級(jí)無疑了。
然而，它并沒有更新版本號(hào)：
可以看到 Nest 從 gulp 切換到了 tsc 編譯，但是版本號(hào)依然是 9.1.2。
為什么這么大的 PR 沒有改版本號(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ì)問了，Project Reference 是什么東西？為什么它能提升 tsc 編譯性能呢？
我們先看下之前 Nest 是怎么編譯 nest 源碼的：
通過 gulp 的 build 命令，產(chǎn)物輸出到 node_modules/@nestjs 下。
gulp 記錄了項(xiàng)目中每一個(gè)包的 tsconfig.json：
然后用 tsc 讀取每一個(gè) tsconfig.json 來編譯 ts 代碼：
這個(gè)流程很容易理解，就是通過 tsc 根據(jù)一個(gè)個(gè)的 tsconfig.json 來編譯 ts 代碼，輸出到不同目錄，gulp 只是組織這個(gè)流程的。
那現(xiàn)在 tsc 又是怎么編譯的呢？
首先，現(xiàn)在不用 gulp 組織流程了，直接執(zhí)行 tsc，只是加上了 -b，這個(gè)就是開啟 project reference 用的：
所謂的 project reference 就是這個(gè)東西：
image.png
也就是 tsconfig 里通過 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)，是否訪問了全局作用域：
這樣再次編譯的時(shí)候有啥不一樣么？
那肯定是編譯過后的就不用編譯了呀，相當(dāng)于做了一層緩存，每次對(duì)比下改動(dòng)的文件的 hash，如果有變化才去編譯。
不同的 project 是分開緩存的，一個(gè) project 變了只要單獨(dú)編譯那個(gè) project 即可，其余的就可以跳過了。
這樣自然就可以提升編譯性能。
不過它提升的只是第二次編譯的性能，首次編譯還是要全量編譯的。
這也是為什么 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": ["/**"],
"type": "node"
} 這個(gè)配置很容易看明白，就是在 01-cats-app 這個(gè)目錄下執(zhí)行 npm run start。
那 console 指定為 integratedTerminal 是什么意思呢？
跑一下就知道了：
跑起服務(wù)來，打個(gè)斷點(diǎn)，訪問 localhost:3000/cats，你會(huì)發(fā)現(xiàn)日志是打印在 debug console 的：
沒有顏色，這自然用的不習(xí)慣。
指定 console 為 integratedTerminal，再重新調(diào)試：
現(xiàn)在日志就打印在 terminal 了，是不是順眼多了？
這是調(diào)試 nest 項(xiàng)目的方式。
那怎么調(diào)試 nest 源碼呢？
現(xiàn)在調(diào)用棧里的 nest 代碼都是編譯過后的：
想調(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 下還是沒有 sourcemap，這是因?yàn)檫€少了一步：
nest 的 build 命令有個(gè)后置命令：
每次 build 完就會(huì)自動(dòng)把這些文件復(fù)制到 node_modules/@nestjs 下：
默認(rèn)沒有編譯出 sourcemap，自然也就沒有 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 最近通過一個(gè)大 PR 把構(gòu)建方式從 gulp + tsc 切換到了 tsc -b 也就是 project reference 的方式，這樣能極大的提升 tsc 編譯性能。
原理就是 project reference 的模式會(huì)生成一個(gè)緩存文件記錄著每個(gè) project 編譯了哪些文件，hash 是啥，這樣再次編譯就可以跳過沒有更新的文件。
新版 nest 源碼的調(diào)試也同樣需要生成 sourcemap，修改下編譯配置，生成 sourcemap 的代碼即可（只不過要注意 VSCode Node Debugger 的一個(gè)坑，默認(rèn)不查找 node_modules下的 sourcemap）。
然后就可以愉快的調(diào)試 nest 的 ts 源碼了！
nest 這么大的項(xiàng)目都用了 tsc project reference 來優(yōu)化編譯性能，那平時(shí)我們的項(xiàng)目自然也可以用 project reference 來優(yōu)化，ts 編譯性能優(yōu)化的時(shí)候不妨往這方面考慮一下。
網(wǎng)站名稱：Nest.js這么大的項(xiàng)目是怎么優(yōu)化ts編譯性能的？
分享路徑：http://m.5511xx.com/article/copsihs.html
