在探索現(xiàn)代 JavaScript 生態(tài)系統(tǒng)時，我們常常會遇到新興技術(shù)的快速迭代和改進(jìn)。其中，包管理工具的發(fā)展尤為重要，因為它們直接影響開發(fā)效率和項目性能。最近，pnpm 作為一種新的包管理工具引起了廣泛關(guān)注。它不僅挑戰(zhàn)了傳統(tǒng)工具如 npm 和 Yarn，還提供了一些獨特的優(yōu)勢，使其在許多方面超越了前輩。

為了更好地理解 pnpm 的優(yōu)勢，我們從包管理工具的歷史開始探索，從 npm2 開始的各個階段。我們將看到 pnpm 如何通過技術(shù)創(chuàng)新解決歷史遺留問題，并極大地提高性能和效率。接下來，深入了解 pnpm 的核心機(jī)制以及它如何改變開發(fā)者處理依賴管理的方式。

npm2

使用 Node 版本管理工具將 Node 版本降級到 4，然后 npm 版本將是 2.x。

在一個目錄中運行 npm init -y 快速創(chuàng)建一個 package.json 文件。

然后運行 npm install express，express 包及其依賴項將被下載：

展開 express，它也有 node_modules：

繼續(xù)展開幾層，每個依賴項都有自己的 node_modules：

換句話說，npm2 的 node_modules 是嵌套的。

這正常嗎？這有什么問題嗎？

實際上，這確實有問題。多個包不可避免地具有共同的依賴項。當(dāng)像這樣嵌套時，相同的依賴項將被多次重復(fù)，占用了相對較大的磁盤空間。

這還不是最大的問題；致命的問題是 Windows 中文件路徑的最大長度超過 260 個字符。像這樣嵌套會超過 Windows 的路徑長度限制。

在 npm 尚未解決這個問題時，社區(qū)出現(xiàn)了一個新的解決方案：yarn。

yarn

Yarn 如何解決重復(fù)依賴和過長嵌套路徑的問題？

扁平化。所有依賴項不再逐層嵌套，而是全部處于同一層級，因此不再存在重復(fù)依賴或路徑過長的問題。

我們刪除 node_modules，使用 Yarn 重新安裝并執(zhí)行 yarn add express：

此時，node_modules 看起來像這樣：

所有依賴項都在同一層級，大多數(shù)包在其下沒有第二層 node_modules：

當(dāng)然，有些包仍然有 node_modules，例如這個：

為什么仍然存在嵌套？

因為一個包可能有多個版本，并且只有一個版本可以被提升。因此，當(dāng)遇到不同版本的同一包時，仍然使用嵌套。

npm 升級到版本 3 后，也采用了這種扁平化解決方案，與 yarn 非常相似：

當(dāng)然，yarn 也實現(xiàn)了 yarn.lock 的功能來鎖定依賴項版本，但 npm 也實現(xiàn)了這一點。

yarn 和 npm 都采用了扁平化解決方案。這種方法沒有問題嗎？

不完全是，扁平化解決方案也有自己的問題。

主要問題是幽靈依賴，這意味著在代碼中可以引入未在依賴項部分聲明的依賴項。

這很容易理解，因為一切都是扁平化的，所以可以找到依賴項的依賴項。

然而，這帶來了風(fēng)險，因為沒有明確的依賴聲明，如果有一天另一個包不再依賴于那個包，你的代碼將無法運行，因為依賴于它，但現(xiàn)在沒有安裝。

這就是幽靈依賴的問題。

另一個問題是多個版本的依賴項，如上所述。只有一個版本會被提升，而其他版本則會重復(fù)多次，導(dǎo)致磁盤空間浪費。

社區(qū)有解決這兩個問題的想法嗎？

當(dāng)然有！這就是為什么引入了 pnpm。

pnpm

回顧一下，為什么 npm3 和 yarn 扁平化 node_modules？不就是因為相同的依賴項會被多次重復(fù)，并且長路徑可能會在 Windows 上引發(fā)問題嗎？

如果我們不重復(fù)它們，而是使用鏈接呢？

首先，介紹鏈接。它是操作系統(tǒng)提供的軟鏈接和硬鏈接。硬鏈接是同一個文件的不同引用，而符號鏈接會創(chuàng)建一個新文件，其內(nèi)容指向另一個路徑。當(dāng)然，這兩種鏈接的使用方式是類似的。

如果不復(fù)制文件，而是將 npm 包的唯一副本存儲在全局倉庫中，并將其他位置鏈接到它呢？

這樣就不會因多次復(fù)制而浪費磁盤空間，也不會有路徑過長的問題。路徑長度的限制本質(zhì)上意味著不應(yīng)該有太深的目錄層級；現(xiàn)在所有位置的目錄是鏈接在一起的，而不是在同一個目錄中，因此沒有長度限制。

是的，pnpm 通過這種方法實現(xiàn)了這一點。

再次刪除 node_modules，然后使用 pnpm 通過運行 pnpm install 重新安裝。

你會注意到它打印出這樣一句話：

軟件包從全局存儲硬鏈接到虛擬存儲，這里的虛擬存儲是 node_modules/.pnpm。

我們打開 node_modules 看一看。

確實不是扁平的，依賴 express，所以在 node_modules 下只有 express，沒有任何幽靈依賴。

展開 .pnpm 看看：

所有依賴項都在這里解決，全部從全局倉庫直接鏈接過來，并通過符號鏈接組織包之間的依賴關(guān)系。

例如，.pnpm 下的 express，都是符號鏈接。

換句話說，所有依賴項都是從全局倉庫硬鏈接到 node_modules/.pnpm，然后它們通過符號鏈接相互依賴。

官方提供了一個示意圖，結(jié)合起來看很清楚：

這就是 pnpm 的實現(xiàn)原理。

pnpm 的優(yōu)越性

首先，最大的優(yōu)勢是節(jié)省磁盤空間。包只在全局保存一份，其余的都是符號鏈接或硬鏈接。這節(jié)省了大量磁盤空間。

其次，它很快，因為它使用鏈接而不是復(fù)制，這自然使它更快。

這些也是它所宣稱的優(yōu)勢：

相比 npm2，優(yōu)勢在于不會多次重復(fù)相同的依賴項。

相比 yarn 和 npm3+，沒有幽靈依賴，也沒有未提升依賴項的重復(fù)問題。

這已經(jīng)足夠優(yōu)秀，可以說是對 yarn 和 npm 的一次打擊。

結(jié)語

最近，pnpm 頻繁被提及，可以說是當(dāng)下的趨勢。在本文中，我們總結(jié)了其受歡迎的原因：

npm2 以嵌套方式管理 node_modules，導(dǎo)致多次重復(fù)依賴項的問題。

npm3+ 和 yarn 通過扁平化方式管理 node_modules，解決了嵌套方式的一些問題，但引入了幽靈依賴的問題。此外，同名包只有一個版本被提升，而其他版本仍會重復(fù)。

pnpm 通過不復(fù)制文件，而是從全局倉庫硬鏈接到 node_modules/.pnpm，并通過符號鏈接組織依賴關(guān)系，解決了這些問題。

這不僅節(jié)省了磁盤空間，消除了幽靈依賴問題，還加快了安裝速度。從機(jī)械角度來看，pnpm 超越了 npm 和 yarn。

通過這種對 npm 和 yarn 的創(chuàng)新方法，pnpm 正在通過簡化依賴管理的方式產(chǎn)生影響。