日韩五月,午夜电影,一级毛片视频

剖析Npm、Yarn 與 Pnpm 依賴管理邏輯

我們在項目開發的過程中會引用到各種不同的庫，各種庫又依賴了其他不同的庫，這些依賴應該如何進行管理，今天這篇文章主要聊的就是這個事情。

npm2的依賴管理npm2 安裝依賴的時候比較簡單直接，直接按照包依賴的樹形結構下載填充本地目錄結構。

比如在項目中A和 C 都依賴 B，無論被依賴的 B 是否是同一個版本，都會直接無腦的生成對應的樹結構，比如我們現在有下面的依賴：

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

剖析Npm、Yarn 與 Pnpm 依賴管理邏輯

這樣的結構非常直觀，但是有一個問題就是，如果項目的依賴過多的話，可能導致下面這些問題：

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

npm3/yarn的依賴管理

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

剖析Npm、Yarn 與 Pnpm 依賴管理邏輯

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

剖析Npm、Yarn 與 Pnpm 依賴管理邏輯

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

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

剖析Npm、Yarn 與 Pnpm 依賴管理邏輯

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

我們項目本身的node_modules結構不夠直觀
依賴不安全，我們可以使用依賴文件中并沒有聲明的npm包

其實第一點的問題并不是很大，主要是第二點可能會導致一些奇怪的問題。以我們之前的例子來說，我們可以直接在項目里面直接使用a_base_klx，因為node_modules里面這兩個包實際上是存在的，但是他們又不是永遠存在的。萬一有一天，a_klx和b_klx里都去除了這兩個基礎包的引用，node_modules里面將不再存在a_base_klx和b_base_klx，那么我們的代碼就會出現問題...也就是：

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

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

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

剖析Npm、Yarn 與 Pnpm 依賴管理邏輯

還是下面這樣的：

剖析Npm、Yarn 與 Pnpm 依賴管理邏輯

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

剖析Npm、Yarn 與 Pnpm 依賴管理邏輯

被提到最外層的包是2.0.0版本的，然后b_klx和d_klx的node_modules下面各自有一個 [email protected]這一塊的內容自己查了一下，大部分說法是會根據package.json里面的順序決定誰會被提出來，放在前面的包依賴的內容會被先提出來。

剖析Npm、Yarn 與 Pnpm 依賴管理邏輯

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

剖析Npm、Yarn 與 Pnpm 依賴管理邏輯

最終會通過localeCompare方法對依賴進行一次排序，所以字典序在前面的npm包的底層依賴會被優先提出來，對于我們的例子來說就是a_klx所依賴的[email protected]會被優先提出來。

pnpm的依賴管理

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

如果我們用pnpm再來安裝一遍上面的依賴，會發現項目的node_modules文件夾只有當前package.json中所聲明的各個依賴(的軟連接)，而真正的模塊文件，存在于node_modules/.pnpm，由模塊名@版本號形式的文件夾扁平化存儲(解決依賴重復安裝)。同時這樣設計，也很好的避免了之前可以訪問非法npm包的問題，因為當前項目的node_modules只有我們聲明過的依賴，這也讓node_modules里面的文件看起來非常的直觀。

剖析Npm、Yarn 與 Pnpm 依賴管理邏輯

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

但是說到硬鏈接，又有一個問題，這相當于所有項目都依賴了同一個文件，那么在一個項目中修改了某個npm包的文件，就會影響到其他項目，這對于postinstall是很不友好的。隨后繼續實操了一下，確實在不同項目中修改了某個npm包后會影響到其他項目。同時自己平時有時候也會直接在node_modules里面調試一些東西..感覺這種處理方式對于這種操作來說也不是很友好。

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

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