4 月 20 日，Vite 4.3 正式發(fā)布。在這個(gè)版本中，Vite 團(tuán)隊(duì)專注于改進(jìn)  devServer 的性能。簡(jiǎn)化了解析邏輯，優(yōu)化了熱路徑，并對(duì)查找 package.json、TS 配置文件和一般解析 URL 實(shí)現(xiàn)了更智能的緩存。與 Vite 4.2 相比，這個(gè)版本的速度得到了全面提升！

性能提升

以下是性能改進(jìn)的具體數(shù)據(jù)，由 sapphi-red/performance-compare 測(cè)試得出，該測(cè)試會(huì)以 1000 個(gè) React 組件測(cè)試應(yīng)用的冷啟動(dòng)和熱啟動(dòng)時(shí)間以及根節(jié)點(diǎn)和葉節(jié)點(diǎn)組件的 HMR 時(shí)間：

此性能運(yùn)行的規(guī)格和版本：

• CPU：Ryzen 9 5900X，內(nèi)存：DDR4-3600 32GB，SSD：WD Blue SN550 NVME SSD
• Windows 10 專業(yè)版 21H2 19044.2846
• Node.js 18.16.0
• Vite 和 React 插件版本

• Vite 4.2 (babel): Vite 4.2.1 + plugin-react 3.1.0
• Vite 4.3 (babel): Vite 4.3.0 + plugin-react 4.0.0-beta.1
• Vite 4.2 (swc): Vite 4.2.1 + plugin-react-swc 3.2.0
• Vite 4.3 (swc): Vite 4.3.0 + plugin-react-swc 3.3.0

Vite 團(tuán)隊(duì)將繼續(xù)致力于提升 Vite 的性能，正在為 Vite 開(kāi)發(fā)一個(gè)官方基準(zhǔn)測(cè)試工具，以獲得每個(gè) Pull Request 的性能指標(biāo)。vite-plugin-inspect 現(xiàn)在有更多與性能相關(guān)的功能，可以幫助開(kāi)發(fā)者確定哪些插件或中間件是應(yīng)用性能的瓶頸。頁(yè)面加載后使用 vite --profile（然后按 p）將保存 devServer 啟動(dòng)的 CPU 配置文件?？梢栽趹?yīng)用中將它們作為 speedscope 打開(kāi)以識(shí)別性能問(wèn)題。

接下來(lái)，Vite 團(tuán)隊(duì)決定今年做一個(gè) Vite 主版本，以配合 9 月 Node.js 16 的 EOL，放棄對(duì) Node.js 14 和 16 的支持。

為什么 Vite 4.3 這么快？

更智能的解析策略

Vite會(huì)將所有接收到的URL和路徑解析為目標(biāo)模塊。在 Vite 4.2 中，存在很多冗余的解析邏輯和不必要的模塊搜索。為了減少計(jì)算和文件系統(tǒng)調(diào)用，Vite 4.3 使解析邏輯更簡(jiǎn)單、更嚴(yán)格和更準(zhǔn)確。

更簡(jiǎn)單的解析

Vite 4.2嚴(yán)重依賴 resolve 包來(lái)解析依賴的 package.json，查看 resolve 的源碼發(fā)現(xiàn)解析 package.json 時(shí)有很多無(wú)用的邏輯。Vite 4.3 摒棄了 resolve，遵循更簡(jiǎn)單的 resolve 邏輯：直接檢查嵌套父目錄中是否存在 package.json。

更嚴(yán)格的解析

Vite 必須調(diào)用 Nodejs fs API 來(lái)查找模塊。但是 IO 很昂貴。Vite 4.3 縮小了文件搜索范圍，并跳過(guò)搜索一些特殊路徑，以盡可能減少 fs 調(diào)用。例如：

1. 由于 # 符號(hào)不會(huì)出現(xiàn)在 URL 中，用戶可以控制源文件路徑中沒(méi)有 # 符號(hào)，因此 Vite 4.3 不再檢查用戶源文件中帶有 # 符號(hào)的路徑，而是僅在 node_modules 中搜索它們。
2. 在Unix系統(tǒng)中，Vite 4.2 會(huì)先檢查根目錄下的每一個(gè)絕對(duì)路徑，對(duì)大多數(shù)路徑都可以，但是如果絕對(duì)路徑以根開(kāi)頭就很容易失敗。為了在 /root/root 不存在的情況下跳過(guò)搜索 /root/root/path-to-file，Vite 4.3 會(huì)在開(kāi)頭判斷 /root/root 作為目錄是否存在，并預(yù)先緩存結(jié)果。
3. 當(dāng) Vite 服務(wù)器收到 @fs/xxx? 和 @vite/xxx 時(shí)，就不需要再解析這些 URL。Vite 4.3 直接返回之前緩存的結(jié)果，不再重新解析。

更準(zhǔn)確的解析

Vite 4.2 在文件路徑為目錄時(shí)遞歸解析模塊，會(huì)導(dǎo)致不必要的重復(fù)計(jì)算。Vite 4.3 將遞歸解析扁平化，并對(duì)不同類型的路徑應(yīng)用適當(dāng)?shù)慕馕?，展平后緩存一?fs 調(diào)用也更容易。

包解析

Vite 4.3 打破了解析 node_modules 包數(shù)據(jù)的性能瓶頸。Vite 4.2 使用絕對(duì)文件路徑作為包數(shù)據(jù)緩存鍵。這還不夠，因?yàn)?Vite 必須遍歷 pkg/foo/bar? 和 pkg/foo/baz 中的同一個(gè)目錄。

Vite 4.3 不僅使用了絕對(duì)路徑(/root/node_modules/pkg/foo/bar.js? & /root/node_modules/pkg/foo/baz.js?)，還使用了遍歷目錄(/root/node_modules/pkg/foo? & /root/node_modules/pkg?) 作為 pkg 緩存的鍵。

另一種情況是，Vite 4.2 在單個(gè)函數(shù)中查找深層導(dǎo)入路徑的 package.json?，例如 Vite 4.2 解析 a/b/c/d? 等文件路徑時(shí)，首先檢查根 a/package.json? 是否存在， 如果沒(méi)有，則按照a/b/c/package.json? -> a/b/package.json?的順序查找最近的package.json?，但事實(shí)是查找根package.json?和最近的package.json?應(yīng)該分開(kāi)處理 ，因?yàn)樵诓煌慕馕錾舷挛闹行枰鼈?。Vite 4.3 將根 package.json? 和最近的 package.json 解析分成兩部分，這樣它們就不會(huì)混在一起。

fs.realpathSync 問(wèn)題

Nodejs 中有一個(gè)有趣的 realpathSync 問(wèn)題，它指出 fs.realpathSync? 比 fs.realpathSync.native? 慢 70 倍。但 Vite 4.2 僅在非 Windows 系統(tǒng)上使用 fs.realpathSync.native?，因?yàn)樗?Windows 上的行為不同。為了解決這個(gè)問(wèn)題，Vite 4.3 在 Windows 上調(diào)用 fs.realpathSync.native 時(shí)添加了網(wǎng)絡(luò)驅(qū)動(dòng)器驗(yàn)證。

非阻塞任務(wù)

作為一個(gè)按需服務(wù)，Vite dev server 可以在沒(méi)有準(zhǔn)備好所有東西的情況下啟動(dòng)。

非阻塞 tsconfig 解析

Vite 服務(wù)器在預(yù)綁定 ts 或 tsx 時(shí)需要 tsconfig 數(shù)據(jù)。

Vite 4.2 在服務(wù)端啟動(dòng)之前，在插件鉤子 configResolved? 中等待 tsconfig? 數(shù)據(jù)解析完成。一旦服務(wù)器啟動(dòng)而沒(méi)有準(zhǔn)備好 tsconfig? 數(shù)據(jù)，頁(yè)面請(qǐng)求就可以訪問(wèn)服務(wù)器，即使請(qǐng)求可能需要稍后等待 tsconfig 解析。

Vite 4.3 會(huì)在服務(wù)器啟動(dòng)前初始化 tsconfig? 解析，但服務(wù)器不會(huì)等待。解析過(guò)程在后臺(tái)運(yùn)行。一旦有ts相關(guān)的請(qǐng)求進(jìn)來(lái)，就得等tsconfig解析完了。

非阻塞文件處理

Vite 中有大量的 fs 調(diào)用，其中一些是同步的。這些同步 fs 調(diào)用可能會(huì)阻塞主線程。Vite 4.3 將它們改為異步。此外，并行化異步函數(shù)也更容易。關(guān)于異步函數(shù)，可能有許多 Promise 對(duì)象在解析后要釋放。由于更智能的解析策略，釋放 fs-Promise 對(duì)象的成本要低得多。

HMR 防抖

考慮兩個(gè)簡(jiǎn)單的依賴鏈 C <- B <- A & D <- B <- A，當(dāng) A 被編輯時(shí)，HMR 將從 A 傳播到 C 和 A 傳播到 D。這導(dǎo)致 A 和 B 在 Vite 4.2 中被更新兩次。

Vite 4.3 緩存了這些遍歷的模塊，以避免多次搜索它們，它適用于由 git checkout 觸發(fā)的 HMR。

并行化

并行化始終是獲得更好性能的好選擇。在 Vite 4.3 中，我們并行化了一些核心功能，包括導(dǎo)入分析、提取 deps 的導(dǎo)出、解析模塊 url 和運(yùn)行批量?jī)?yōu)化器。

Javascript 優(yōu)化

用回調(diào)替換 *yield

Vite 使用 tsconfck? 來(lái)查找和解析 tsconfig? 文件。tsconfck? 曾經(jīng)通過(guò) *yield? 遍歷目標(biāo)目錄，生成器的一個(gè)缺點(diǎn)是它需要更多的內(nèi)存空間來(lái)存儲(chǔ)它的生成器對(duì)象，并且在運(yùn)行時(shí)會(huì)有大量的生成器上下文切換。所以從 v2.1.1 開(kāi)始在核心中用回調(diào)替換 ??*yield??。

使用 === 代替 startsWith 和 endsWith

Vite 4.2 使用 startsWith? 和 endsWith? 檢查熱更新 URL 中的頭部和尾部 '/'。比較 str.startsWith('x')? 和 str[0] === 'x'? 的執(zhí)行基準(zhǔn)發(fā)現(xiàn)，===? 比 startsWith? 快約 20%，endsWith 比 === 慢約 60%。

避免重復(fù)創(chuàng)建正則表達(dá)式

Vite 需要很多正則表達(dá)式來(lái)匹配字符串，其中大部分都是靜態(tài)的，因此只使用它們的單例會(huì)更好。Vite 4.3 將正則表達(dá)式提升，以便可以重復(fù)使用它們。

放棄生成自定義錯(cuò)誤

在 Vite 4.2 中，有一些自定義錯(cuò)誤以改進(jìn)開(kāi)發(fā)體驗(yàn)。這些錯(cuò)誤可能會(huì)導(dǎo)致額外的計(jì)算和垃圾回收，從而降低 Vite 的速度。在 Vite 4.3 中，放棄了生成某些熱更新自定義錯(cuò)誤（例如 package.json NOT_FOUND 錯(cuò)誤），直接拋出原始錯(cuò)誤以獲得更好的性能。

參考資料：

• https://vitejs.dev/blog/announcing-vite4-3.html。
• https://sun0day.github.io/blog/vite/why-vite4_3-is-faster.html。