npm2的依賴管理

npm2 安裝依賴的時候比較簡單直接，直接按照包依賴的樹形結(jié)構(gòu)下載填充本地目錄結(jié)構(gòu)。

比如在項目中A和 C 都依賴 B，無論被依賴的 B 是否是同一個版本，都會直接無腦的生成對應(yīng)的樹結(jié)構(gòu)，比如我們現(xiàn)在有下面的依賴：

• A@2.0.0：BaseA@1.0.0 BaseB@2.0.0
• B@3.0.0：BaseA@1.0.0 BaseB@2.0.1

那么npm i之后node_modules里面生成的內(nèi)容將是下面這樣的

這樣的結(jié)構(gòu)非常直觀，但是有一個問題就是，如果項目的依賴過多的話，可能導(dǎo)致下面這些問題：

1. 生成的依賴嵌套非常深
2. 相同版本的依賴大量冗余

npm3/yarn的依賴管理

npm3對于npm2的情況進行了優(yōu)化，那么如何進行優(yōu)化呢？其實我們最直觀的思路就是將樹打平，將依賴扁平化，不就能解決嵌套過深和依賴冗余的問題。所以，在上面的例子中，如果我們用npm3來進行install，最后生成的node_modules會是這樣的結(jié)構(gòu)：

這樣看起來是不是就好多了，但是此時會有什么問題呢？我們實操一下試試看。在項目中安裝A和B

可以看到我們項目本身的依賴文件里面只有a_klx和b_klx，但是執(zhí)行完npm i命令后卻發(fā)現(xiàn)多了幾個我們沒有引入的包a_base_klx和b_base_klx。

其實這是由a_klx和b_klx本身自己引入的npm包，但是卻出現(xiàn)在了我們的node_modules下。那么如果我們直接使用這兩個包會有什么反應(yīng)呢？

可以看到，我們是可以正常使用這兩個我們并未聲明在依賴中的npm包的，因為這兩個包存在于我們項目的node_modules下，根據(jù)npm包的查找規(guī)則，我們是可以找到這兩個包的。所以這種依賴關(guān)系就導(dǎo)致了下面兩個問題：

1. 我們項目本身的node_modules結(jié)構(gòu)不夠直觀
2. 依賴不安全，我們可以使用依賴文件中并沒有聲明的npm包

其實第一點的問題并不是很大，主要是第二點可能會導(dǎo)致一些奇怪的問題。以我們之前的例子來說，我們可以直接在項目里面直接使用a_base_klx，因為node_modules里面這兩個包實際上是存在的，但是他們又不是永遠存在的。

萬一有一天，a_klx和b_klx里都去除了這兩個基礎(chǔ)包的引用，node_modules里面將不再存在a_base_klx和b_base_klx，那么我們的代碼就會出現(xiàn)問題...也就是：

我的代碼啥也沒動，放了一個晚上就壞了!

同時，我們對于這種處理方式其實很容易有一個疑問，如果我同時引用了同一個包的多個不同版本，會幫我把哪個包提出來，同時我每次npm i之后提出來的包版本都是一樣的嗎？會不會存在這次是2.0.0版本下次是2.0.1版本的情況，比如我們下面這種情況：

•  A@1.0.0：BaseA@1.0.0 BaseB@2.0.0
• B@1.0.0：BaseA@1.0.0 BaseB@2.0.1
• D@1.0.0：BaseA@1.0.0 BaseB@2.0.1

生成的依賴是下面這樣的：

還是下面這樣的：

其實看起來后面這個更合理，因為有兩個包用到了2.0.1版本，將它提出來更好，我們實際操作一下試試：

被提到最外層的包是2.0.0版本的，然后b_klx和d_klx的node_modules下面各自有一個 b_base_klx@2.0.1

這一塊的內(nèi)容自己查了一下，大部分說法是會根據(jù)package.json里面的順序決定誰會被提出來，放在前面的包依賴的內(nèi)容會被先提出來。

不過自己實操了一下發(fā)現(xiàn)并不是這樣，即使我把b_klx或者d_klx移到最前面，被提出來的包依然是a_klx依賴的2.0.0版本，隨后自己翻了一下npm的源碼，發(fā)現(xiàn)內(nèi)部其實會對拿到的依賴列表進行一些處理

最終會通過localeCompare方法對依賴進行一次排序，所以字典序在前面的npm包的底層依賴會被優(yōu)先提出來，對于我們的例子來說就是a_klx所依賴的b_base_klx@2.0.0會被優(yōu)先提出來。

pnpm的依賴管理

pnpm為了解決上述這些問題，采用了一種不同于npm/yarn的依賴管理方式。

如果我們用pnpm再來安裝一遍上面的依賴，會發(fā)現(xiàn)項目的node_modules文件夾只有當前package.json中所聲明的各個依賴（的軟連接），而真正的模塊文件，存在于node_modules/.pnpm，由模塊名@版本號形式的文件夾扁平化存儲(解決依賴重復(fù)安裝)。

同時這樣設(shè)計，也很好的避免了之前可以訪問非法npm包的問題，因為當前項目的node_modules只有我們聲明過的依賴，這也讓node_modules里面的文件看起來非常的直觀。

同時，node_modules/.pnpm中存儲的文件其實是pnpm實際緩存文件的「硬鏈接」，從而避免了多個項目帶來多份相同文件引起的空間浪費問題。

但是說到硬鏈接，又有一個問題，這相當于所有項目都依賴了同一個文件，那么在一個項目中修改了某個npm包的文件，就會影響到其他項目，這對于postinstall是很不友好的。

隨后繼續(xù)實操了一下，確實在不同項目中修改了某個npm包后會影響到其他項目。同時自己平時有時候也會直接在node_modules里面調(diào)試一些東西..感覺這種處理方式對于這種操作來說也不是很友好。

但是從pnpm的官網(wǎng)來看，其實它默認會使用copy-on-write 的方式來進行處理，也就是如果你嘗試對內(nèi)容進行修改的話，會復(fù)制一份文件而不會影響到源文件。

然后它不生效的原因似乎是因為libuv的bug：https://github.com/pnpm/pnpm/issues/2761，所以在copy-on-write不生效的情況下被回退到了hardlink  的方式去處理。