npm2的依賴管理

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

比如在項(xiàng)目中A和 C 都依賴 B，無(wú)論被依賴的 B 是否是同一個(gè)版本，都會(huì)直接無(wú)腦的生成對(duì)應(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)非常直觀，但是有一個(gè)問(wèn)題就是，如果項(xiàng)目的依賴過(guò)多的話，可能導(dǎo)致下面這些問(wèn)題：

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

npm3/yarn的依賴管理

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

這樣看起來(lái)是不是就好多了，但是此時(shí)會(huì)有什么問(wèn)題呢？我們實(shí)操一下試試看。在項(xiàng)目中安裝A和B

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

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

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

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

其實(shí)第一點(diǎn)的問(wèn)題并不是很大，主要是第二點(diǎn)可能會(huì)導(dǎo)致一些奇怪的問(wèn)題。以我們之前的例子來(lái)說(shuō)，我們可以直接在項(xiàng)目里面直接使用a_base_klx，因?yàn)閚ode_modules里面這兩個(gè)包實(shí)際上是存在的，但是他們又不是永遠(yuǎn)存在的。

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

我的代碼啥也沒(méi)動(dòng)，放了一個(gè)晚上就壞了!

同時(shí)，我們對(duì)于這種處理方式其實(shí)很容易有一個(gè)疑問(wèn)，如果我同時(shí)引用了同一個(gè)包的多個(gè)不同版本，會(huì)幫我把哪個(gè)包提出來(lái)，同時(shí)我每次npm i之后提出來(lái)的包版本都是一樣的嗎？會(huì)不會(huì)存在這次是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

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

還是下面這樣的：

其實(shí)看起來(lái)后面這個(gè)更合理，因?yàn)橛袃蓚€(gè)包用到了2.0.1版本，將它提出來(lái)更好，我們實(shí)際操作一下試試：

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

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

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

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

pnpm的依賴管理

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

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

同時(shí)這樣設(shè)計(jì)，也很好的避免了之前可以訪問(wèn)非法npm包的問(wèn)題，因?yàn)楫?dāng)前項(xiàng)目的node_modules只有我們聲明過(guò)的依賴，這也讓node_modules里面的文件看起來(lái)非常的直觀。

同時(shí)，node_modules/.pnpm中存儲(chǔ)的文件其實(shí)是pnpm實(shí)際緩存文件的「硬鏈接」，從而避免了多個(gè)項(xiàng)目帶來(lái)多份相同文件引起的空間浪費(fèi)問(wèn)題。

但是說(shuō)到硬鏈接，又有一個(gè)問(wèn)題，這相當(dāng)于所有項(xiàng)目都依賴了同一個(gè)文件，那么在一個(gè)項(xiàng)目中修改了某個(gè)npm包的文件，就會(huì)影響到其他項(xiàng)目，這對(duì)于postinstall是很不友好的。

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

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

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