“幽靈殺手” pnpm是怎么做到“又快又省又穩”（扒一扒pnpm實現原理）
Hi! 這里是剛吃完鮮蝦魚板面的JustHappy,上一次我們聊了聊主流的npm軟件包下載器，其中pnpm似乎是目前各方面最屌的一個，所以這次我們來深扒一下pnpm的實現原理，也就是pnpm是如何“殺死幽靈”以及“又快又省又穩的”，本文將會結合pnpm的官方文檔進行解析
圖片
可能pnpm的特性比較多，小弟能力暫時有限，本篇文章只會涉及部分pnpm特性，如果大家有興趣，可以去官方文檔查看pnpm中文文檔 | pnpm中文網[1]
首先你得先搞明白“硬鏈接”和“軟鏈接”
是吧！死去的回憶又回來了，這倆是否讓你想起了逃過的計算機操作系統？沒關系，我們再來回顧一下
大白話回顧基礎概念
“硬鏈接（Hard Link）”
硬鏈接是咱文件系統中的一個數據實體，它是直接指向咱硬盤上的數據塊的，也就是說硬鏈接就是目標文件的另一個名字，如果目標文件被刪除，硬鏈接依然有效，這怎么說呢？因為咱執行刪除目標文件這一操作只是刪除了該目標文件在文件系統中的一個名字，只要目標文件的數據還有一個硬鏈接，那么這個數據就不會被真正的刪除
“軟鏈接 (Symbolic Link)”
軟鏈接，又叫做符號鏈接，這個比硬鏈接要好理解些，windows的快捷方式大家都使用過吧，軟鏈接就是一個指向文件或者目錄（文件路徑）的快捷方式，你刪除快捷方式的時候原文件不會受影響
以下是我將一些特性匯總了一個表格
特性 | 硬鏈接 (Hard Link) | 軟鏈接 (Symbolic Link) |
定義 | 一個指向文件inode的引用 | 一個指向文件路徑的引用 |
目標 | 必須指向文件，不能指向目錄 | 可以指向文件或目錄 |
刪除原文件 | 刪除原文件不會連接硬鏈接 | 刪除原文連接軟鏈接變為“死鏈接” |
權限 | 硬鏈接和原文件共享相同的權限 | 軟鏈接有自己的權限設置 |
空間占用 | 不占用額外空間（除了目錄項） | 占用少量空間來存儲鏈接目標路徑 |
移動/重命名 | 移動或重命名原文件會影響硬鏈接 | 移動或重命名原文件不會影響軟鏈接，但軟鏈接會指向錯誤路徑 |
我們先來看看使用pnpm生成的node_modules是什么樣的
圖片
如果你仔細比對，會發現node_modules的一級目錄下所出現的包都是在項目的package.json中已經被聲明的
我們還看到相比于使用npm構建的node_module,這里多了個 .pnpm文件夾,這其實是node_modules中存放包硬鏈接的地方
.pnpm 目錄下的文件結構可以參照下圖
圖片
注：點我去官方文檔[2]
我們來對比npm畫幾張圖吧
我們來回顧一下npm的node_module結構吧：
圖片
可以看到這是一個扁平化的結構，這直接導致了幽靈依賴的出現
那么結合上面對pnpm的分析，我們可以初步得到以下結構(本人自己畫的，如果難看的話望見諒哈)：
圖片
好吧，可能有些復雜，但是不慌，接下來我們結合這個圖講pnpm的三層尋址
pnpm的三層尋址
pnpm的三層尋址策略是其高效存儲和依賴管理的核心機制，具體包括以下三個層面：
第一層：全局的 pnpm 存儲
- 目的：允許跨項目共享依賴，進一步減少存儲和下載的冗余。
- 原理：pnpm維護了一個全局的存儲（通常位于用戶的home目錄下），在其中保存了所有下載的包的版本。這些版本被硬鏈接到項目的.pnpm目錄。
這有什么好處呢？
這其實實現了一個 跨項目共享依賴 的目的，這意味著，不同的項目可以共享全局存儲中的同一個物理文件，從而不需要重復下載或存儲相同的文件。（極大了節省了下載依賴的時間）
第二層：項目級的 .pnpm 目錄
- 目的：.pnpm文件夾內使用的是硬鏈接。這意味著每個包的文件都是硬鏈接到全局存儲中的文件。這些硬鏈接為單個項目提供一個集中的地方來存儲其所有依賴的軟鏈接（或符號鏈接），以減少重復并確保穩定的包結構。
- 原理：每個項目中的.pnpm目錄鏈接到全局pnpm存儲中的依賴版本。項目的node_modules目錄中的每個依賴實際上都是指向這個.pnpm目錄中的相應版本的軟鏈接。
.pnpm的作用
這確保了項目內的node_modules可以維持一個干凈和結構化的布局，而真正的包文件都存儲在全局存儲中，并通過項目級的.pnpm目錄鏈接。
第三層：本地 node_modules
- 目的：維持項目結構的語義性，提供一個確定性的依賴解析方式。
- 原理：每個項目的node_modules目錄中的直接依賴都被組織成與package.json中聲明的結構相匹配的方式。這遵循了Node.js的模塊解析邏輯，確保每個依賴都能被正確地找到。
我們得到了一個更加接近Node.js模塊解析邏輯的目錄結構，并解決了“幽靈依賴”
幽靈依賴（Phantom Dependency）是指在項目中使用了某些依賴包，但這些包沒有顯式地聲明在項目的依賴列表（如 package.json 文件）中。這種依賴的存在通常是因為它被其他依賴的依賴（即間接依賴）提供，而不是項目直接安裝的。
到此，我們得到了一個接近Node.js模塊解析邏輯的 “非扁平的” node_modules結構
可能有些混亂，我們再來總結一遍
總結！為什么說！又快！又省！又穩！
有關于“快”
- pnpm擁有一個全局的存儲空間，所有的npm包都存儲在這個位置。這意味著，無論我們有多少個項目，對于同一個npm包，我們只需要下載一次并存儲一次在全局pnpm存儲中。這樣，當我們在不同項目中需要同一個包時，pnpm可以直接從全局存儲中鏈接，而不需要重復下載。
- 在每個項目的node_modules目錄中，pnpm使用軟鏈接（符號鏈接）或硬鏈接來引用全局存儲中的包。這些鏈接指向全局存儲中的實際文件，因此，無論在哪個項目中，我們都能快速訪問到這些包，而不需要等待重復的下載過程。
- 由于pnpm避免了重復下載相同的包，它大大減少了網絡請求和磁盤I/O操作，這在網絡速度較慢或磁盤I/O性能有限的環境中尤其有用。
- 在安裝新項目依賴時，pnpm首先檢查全局存儲中是否已經存在所需的包。如果存在，它將直接鏈接到項目中，而不是重新下載，這大大加快了安裝速度。
- pnpm支持并行安裝，這意味著它可以同時下載多個包，而不是一個接一個地下載，這進一步提高了安裝速度。
有關于“省”
上面提到，pnpm有一個全局的pnpm存儲，所有的項目中軟鏈接、硬鏈接都是鏈接這里面的npm包這意味這在我們的電腦上對于同一個npm包我們只需要下載一次、存儲一次在我們全局的pnpm存儲中，從而實現了對磁盤空間的”省“，不像之前使用npm或者yarn的時候，將所有的依賴安裝到項目文件夾的node_modules下，從而導致了在我們電腦上多次、重復的下載。
有關于“穩”
- 基于鏈接的node_modules結構：pnpm通過軟鏈接將項目的依賴直接鏈接到虛擬store下對應包的版本下，然后虛擬store對應版本會直接硬鏈接到全局的pnpm store下。這種布局的一大好處是只有真正在依賴項中的包才能訪問，避免了幽靈依賴問題。
- 嚴格的依賴平面：pnpm為每個包提供獨立的依賴視圖，減少了不必要的包冗余。這種嚴格的控制有助于防止版本沖突，確保每個包的依賴關系都被滿足，減少了因版本不匹配導致的問題。
文章作者：JustHappy
原文地址：https://juejin.cn/post/7443866293755592742
