關于包管理器Npm、Yarn和Pnpm的一些總結-魔扣目錄

寫在前面

在Node.js生態系統中，包管理器是至關重要的組件之一，它們負責維護各種應用程序和庫之間的依賴關系。npm是Node.js的默認包管理器，它的初始版本是npm1，但是它很快就被npm2所取代。

npm2

關于npm2最初作為包管理管理，采用的是node_modules嵌套模式，即每個包都會有自己獨立的node_modules，且會將各自依賴進行安裝，依賴的依賴也會產生自己的node_modules，這樣就產生了“嵌套依賴”。

就像回調嵌套一樣，容易陷入回調地獄，嵌套依賴也不例外。

這種嵌套依賴的模式，雖然可以使依賴項的版本更加明確和穩定，但是在實際應用中也存在一些問題。其中最大的問題是包的嵌套層級很深，這可能會導致安裝和更新依賴項的時間變長，并增加包的大小。此外，由于每個包都有自己的node_modules文件夾，這可能會導致文件系統中出現大量重復的依賴項，從而占用更多的磁盤空間。

在實際操作中，當需要在特定的Node.js版本中使用npm2時，可以使用Node Version Manager (nvm)來管理多個Node.js版本。例如，在切換到Node.js v4.0版本時，對應的npm版本是npm2.x。

為了更好地說明嵌套依賴的問題，我們可以通過安裝koa來演示。koa是一個基于Node.js的Web應用程序框架，它有許多依賴項，我們可以使用以下命令來安裝koa：

npm install koa

在安裝koa時，npm會自動下載和安裝所有必需的依賴項，并將它們安裝到koa的node_modules文件夾中。如果我們檢查koa的node_modules文件夾，我們會發現它包含了大量的依賴項，這些依賴項中又包含了更多的依賴項，導致整個文件夾的嵌套層級變得很深。

對于多包之間會存在公共依賴，如果對于每個依賴都生成自己獨立的node_modules，那么就會對相同包重復安裝多次，這就會占據很大的磁盤空間。且無限嵌套，也會超過windows的最大文件路徑長度限制（265個字符）。

嵌套依賴項的模式是npm2中的一個特性，雖然可以保證依賴項的版本穩定性和精確性，但是它可能會導致嵌套層級變得很深，并占用大量的磁盤空間。

yarn

我們想到，既然樹形結構存在弊端，為什么不將依賴包在根node_modules進行扁平化處理，這不就解決了依賴嵌套、依賴重復和路徑限制問題了？

此時新方式yarn就橫空誕生。

當使用yarn進行依賴管理時，我們可以看到所有依賴都會被安裝在根目錄下的node_modules文件夾中。與npm2不同的是，yarn采用了扁平依賴項的模式，這意味著相同的依賴包只會被安裝一次，并且不會存在多個嵌套的node_modules文件夾。

使用yarn add koa進行安裝，可以看到通過yarn進行管理的依賴全部平鋪在根node_modules下，且沒有重復依賴安裝的問題。

但是，當某些依賴包存在多個版本時，yarn會將其中一個版本提升到根node_modules文件夾中，而其他依賴包則會繼續維護自己的版本。這可能會導致某些依賴包無法正常工作，因為它們可能需要使用特定版本的依賴包。為了解決這個問題，yarn仍然需要使用嵌套的node_modules文件夾，以確保每個依賴包使用正確的版本。

值得注意的是，yarn采用的扁平依賴項模式具有許多優點，例如更快的安裝速度，更少的磁盤空間占用和更少的依賴沖突問題。此外，yarn還提供了一個lock文件，該文件記錄了所有依賴項的確切版本和位置，以確保依賴項的版本穩定性和一致性。

yarn的變與不變：

yarn采用了更加高效和可靠的依賴項管理方式，可以有效地避免依賴沖突和嵌套的問題。但是，對于某些多版本依賴包，yarn仍然需要使用node_modules嵌套的方式來確保每個依賴包都使用正確的版本。

npm3

npm3在2015年發布時引入了一種新的依賴項安裝算法，稱為“扁平依賴項”。其主要原理是通過將所有依賴項都放置在同一個目錄下，并使用符號鏈接來實現依賴項的共享。

在npm3中，所有依賴項都被直接安裝到根目錄下的node_modules中，而不是像npm2一樣在每個依賴包中嵌套一個node_modules目錄。這種扁平化的結構可以減少依賴項的嵌套層級，從而降低了磁盤空間的占用和文件路徑的長度。在這種模式下，所有依賴項都被安裝到頂級node_modules文件夾中，這樣就避免了嵌套依賴項的問題。這種模式雖然簡單，但是它可能會導致依賴項的版本不穩定，從而可能會導致依賴沖突的問題。

當我們使用npm3安裝koa包時，它會首先檢查該包所需的所有依賴項是否已經安裝，如果沒有安裝，則會將這些依賴項直接安裝到根目錄下的node_modules目錄中。同時，npm3會使用符號鏈接將這些依賴項鏈接到需要使用它們的包的node_modules目錄下。

通過使用符號鏈接，npm3可以實現依賴項的共享，從而避免了依賴項的重復安裝和占用大量的磁盤空間。此外，npm3還支持npm shrinkwrap命令，可以生成一個lockfile文件，記錄每個包所使用的依賴項的精確版本號，從而避免了版本沖突和不兼容的問題。

shrinkwrap 文件的作用是什么？

這個文件用于記錄整個依賴樹的結構和依賴包的版本信息，可以保證依賴包的版本穩定性和一致性。

那么使用扁平化方案就能完美解決以上問題嗎？當然不是。

幽靈依賴：在聲明中沒有使用dependencies中的依賴，代碼中也可以進行reqiure引入。沒有在項目中進行顯式依賴，如果別的包不再依賴這個包，就會導致代碼因為依賴這個包，而沒有進行安裝，最終不能正常運行。
磁盤浪費：對于依賴包只會提升一個，存在多個版本時其余包同樣得進行拷貝到各自node_modules下，依然會存在磁盤空間浪費。

什么是幽靈依賴？

在安裝和使用某個第三方包時，該包依賴的其他依賴沒有在它的js文件中顯式引入的情況。這些依賴可能在代碼中被引用，但是沒有被包含在軟件包的package.json文件中。這種情況被稱為“幽靈依賴”。

舉個例子，假設有個項目需要依賴包 A 和 B，而這兩個包都依賴于包 C，但是包 A 依賴于包 C 的版本 1.0.0，而包 B 依賴于包 C 的版本 2.0.0。在 npm2 中，這兩個版本的包 C 會被分別安裝在 A 和 B 的 node_modules 目錄下，不會產生沖突。但在 npm3 中，這兩個版本的包 C 可能會被安裝在同一個 node_modules 目錄下，這時候就會產生沖突，導致代碼無法運行。

雖然在npm3提供了 npm dedupe 命令，可以是手動輸入命令將重復的依賴項合并到頂層 node_modules 目錄下，避免了幽靈依賴的問題。但是好像并沒有很智能。

總的來說，npm3通過采用扁平化的依賴管理結構和符號鏈接機制，引入 shrinkwrap 文件實現了依賴項的共享和版本精確控制，并且減少了依賴項的嵌套層級和磁盤空間占用。可以手動使用 dedupe 命令等方式，解決了 npm2 中出現的幽靈依賴問題，提高了包管理的效率和可靠性。

pnpm

針對上面遺留下的兩個問題，pnpm橫空出世，采用硬鏈接和符號鏈接來管理依賴項，以減少重復下載和占用空間，從而有效地解決幽靈依賴和磁盤浪費的問題。

基于內容尋址的文件系統來存儲磁盤的文件
不會重復安裝同一個包，只在磁盤中寫入一次，而后在使用的地方通過hardlink
同包不同版本，也盡可能復用代碼

link：也就是軟硬連接，這是操作系統提供的機制。

硬連接就是同一個文件的不同引用
軟鏈接是新建一個文件，文件內容指向另一個路徑

具體來說，當使用 pnpm 安裝koa包的依賴項時，它會首先檢查系統上是否已經安裝了所需的依賴項。如果已經安裝，則 pnpm 將創建一個符號鏈接到該依賴項，而不是在當前項目中復制該依賴項。這樣就避免了重復下載和占用磁盤空間的問題。

我們在命令行輸入:

pnpm add koa

此外，pnpm 還支持不同的包引用方式，如路徑引用和 git 倉庫引用，這使得 pnpm 可以更快地安裝依賴項并減少重復下載，從而提高開發效率和依賴項管理的可靠性。通過將包從全局 store 進行硬鏈接到項目的虛擬 store 中，pnpm 可以避免多次拷貝文件和深度嵌套路徑過長的問題，從而進一步減少磁盤空間的占用和提高性能。