關于現(xiàn)代包管理器的深度思考-為什么現(xiàn)在我更推薦 pnpm 而不是 npm/yarn?
很長時間沒有更新原創(chuàng)文章了，但是還一直在思考和沉淀當中，后面公眾號會更頻繁地輸出一些前端工程相關的干貨，希望對大家有一些啟發(fā)，也希望在實際的工作當中幫助大家提升效率。
這篇文章給大家分享一個業(yè)內(nèi)一款出色的包管理器——pnpm。目前 GitHub 已經(jīng)有 star 9.8k，現(xiàn)在已經(jīng)相對成熟且穩(wěn)定了。它由 npm/yarn 衍生而來，但卻解決了 npm/yarn 內(nèi)部潛在的 bug，并且極大了地優(yōu)化了性能，擴展了使用場景。下面是本文的思維導圖:
一、什么是 pnpm ?
pnpm 的官方文檔(https://pnpm.js.org/en/)是這樣說的:
- Fast, disk space efficient package manager
因此，pnpm 本質(zhì)上就是一個包管理器，這一點跟 npm/yarn 沒有區(qū)別，但它作為殺手锏的兩個優(yōu)勢在于:
- 包安裝速度極快;
- 磁盤空間利用非常高效。
它的安裝也非常簡單。可以有多簡單?
- npm i -g pnpm
二、特性概覽
1. 速度快
pnpm 安裝包的速度究竟有多快?先以 React 包為例來對比一下:
可以看到，作為黃色部分的 pnpm，在絕多大數(shù)場景下，包安裝的速度都是明顯優(yōu)于 npm/yarn，速度會比 npm/yarn 快 2-3 倍。
對 yarn 比較熟悉的同學可能會說，yarn 不是有 PnP 安裝模式(https://classic.yarnpkg.com/en/docs/pnp/)嗎?直接去掉 node_modules，將依賴包內(nèi)容寫在磁盤，節(jié)省了 node 文件 I/O 的開銷，這樣也能提升安裝速度。(具體原理見這篇文章(https://loveky.github.io/2019/02/11/yarn-pnp/))
接下來，我們以這樣一個倉庫(https://github.com/pnpm/benchmarks-of-javascript-package-managers)為例，我們來看一看 benchmark 數(shù)據(jù)，主要對比一下 pnpm 和 yarn PnP:
從中可以看到，總體而言，pnpm 的包安裝速度還是明顯優(yōu)于 yarn PnP的。
2. 高效利用磁盤空間
pnpm 內(nèi)部使用基于內(nèi)容尋址的文件系統(tǒng)來存儲磁盤上所有的文件，這個文件系統(tǒng)出色的地方在于:
- 不會重復安裝同一個包。用 npm/yarn 的時候，如果 100 個項目都依賴 lodash，那么 lodash 很可能就被安裝了 100 次，磁盤中就有 100 個地方寫入了這部分代碼。但在使用 pnpm 只會安裝一次，磁盤中只有一個地方寫入，后面再次使用都會直接使用 hardlink(硬鏈接，不清楚的同學詳見這篇文章(https://www.cnblogs.com/itech/archive/2009/04/10/1433052.html))。
- 即使一個包的不同版本，pnpm 也會極大程度地復用之前版本的代碼。舉個例子，比如 lodash 有 100 個文件，更新版本之后多了一個文件，那么磁盤當中并不會重新寫入 101 個文件，而是保留原來的 100 個文件的 hardlink，僅僅寫入那一個新增的文件。
3. 支持 monorepo
隨著前端工程的日益復雜，越來越多的項目開始使用 monorepo。之前對于多個項目的管理，我們一般都是使用多個 git 倉庫，但 monorepo 的宗旨就是用一個 git 倉庫來管理多個子項目，所有的子項目都存放在根目錄的packages目錄下，那么一個子項目就代表一個package。如果你之前沒接觸過 monorepo 的概念，建議仔細看看這篇文章(https://www.perforce.com/blog/vcs/what-monorepo)以及開源的 monorepo 管理工具lerna(https://github.com/lerna/lerna#readme)，項目目錄結構可以參考一下 babel 倉庫(https://github.com/babel/babel)。
pnpm 與 npm/yarn 另外一個很大的不同就是支持了 monorepo，體現(xiàn)在各個子命令的功能上，比如在根目錄下 pnpm add A -r, 那么所有的 package 中都會被添加 A 這個依賴，當然也支持 --filter字段來對 package 進行過濾。
4. 安全性高
之前在使用 npm/yarn 的時候，由于 node_module 的扁平結構，如果 A 依賴 B， B 依賴 C，那么 A 當中是可以直接使用 C 的，但問題是 A 當中并沒有聲明 C 這個依賴。因此會出現(xiàn)這種非法訪問的情況。但 pnpm 腦洞特別大，自創(chuàng)了一套依賴管理方式，很好地解決了這個問題，保證了安全性，具體怎么體現(xiàn)安全、規(guī)避非法訪問依賴的風險的，后面再來詳細說說。
三、依賴管理
npm/yarn install 原理
主要分為兩個部分, 首先，執(zhí)行 npm/yarn install之后，包如何到達項目 node_modules 當中。其次，node_modules 內(nèi)部如何管理依賴。
執(zhí)行命令后，首先會構建依賴樹，然后針對每個節(jié)點下的包，會經(jīng)歷下面四個步驟:
- 1. 將依賴包的版本區(qū)間解析為某個具體的版本號
- 2. 下載對應版本依賴的 tar 包到本地離線鏡像
- 3. 將依賴從離線鏡像解壓到本地緩存
- 4. 將依賴從緩存拷貝到當前目錄的 node_modules 目錄
然后，對應的包就會到達項目的node_modules當中。
那么，這些依賴在node_modules內(nèi)部是什么樣的目錄結構呢，換句話說，項目的依賴樹是什么樣的呢?
在 npm1、npm2 中呈現(xiàn)出的是嵌套結構，比如下面這樣:
- node_modules
- └─ foo
- ├─ index.js
- ├─ package.json
- └─ node_modules
- └─ bar
- ├─ index.js
- └─ package.json
如果 bar 當中又有依賴，那么又會繼續(xù)嵌套下去。試想一下這樣的設計存在什么問題:
- 依賴層級太深，會導致文件路徑過長的問題，尤其在 window 系統(tǒng)下。
- 大量重復的包被安裝，文件體積超級大。比如跟 foo 同級目錄下有一個baz，兩者都依賴于同一個版本的lodash，那么 lodash 會分別在兩者的 node_modules 中被安裝，也就是重復安裝。
- 模塊實例不能共享。比如 React 有一些內(nèi)部變量，在兩個不同包引入的 React 不是同一個模塊實例，因此無法共享內(nèi)部變量，導致一些不可預知的 bug。
接著，從 npm3 開始，包括 yarn，都著手來通過扁平化依賴的方式來解決這個問題。相信大家都有這樣的體驗，我明明就裝個 express，為什么 node_modules里面多了這么多東西?
沒錯，這就是扁平化依賴管理的結果。相比之前的嵌套結構，現(xiàn)在的目錄結構類似下面這樣:
- node_modules
- ├─ foo
- | ├─ index.js
- | └─ package.json
- └─ bar
- ├─ index.js
- └─ package.json
所有的依賴都被拍平到node_modules目錄下，不再有很深層次的嵌套關系。這樣在安裝新的包時，根據(jù) node require 機制，會不停往上級的node_modules當中去找，如果找到相同版本的包就不會重新安裝，解決了大量包重復安裝的問題，而且依賴層級也不會太深。
之前的問題是解決了，但仔細想想這種扁平化的處理方式，它真的就是無懈可擊嗎?并不是。它照樣存在諸多問題，梳理一下:
- 依賴結構的不確定性。
- 扁平化算法本身的復雜性很高，耗時較長。
- 項目中仍然可以非法訪問沒有聲明過依賴的包
后面兩個都好理解，那第一點中的不確定性是什么意思?這里來詳細解釋一下。
假如現(xiàn)在項目依賴兩個包 foo 和 bar，這兩個包的依賴又是這樣的:
那么 npm/yarn install 的時候，通過扁平化處理之后，究竟是這樣
還是這樣?
答案是: 都有可能。取決于 foo 和 bar 在 package.json中的位置，如果 foo 聲明在前面，那么就是前面的結構，否則是后面的結構。
這就是為什么會產(chǎn)生依賴結構的不確定問題，也是 lock 文件誕生的原因，無論是package-lock.json(npm 5.x才出現(xiàn))還是yarn.lock，都是為了保證 install 之后都產(chǎn)生確定的node_modules結構。
盡管如此，npm/yarn 本身還是存在扁平化算法復雜和package 非法訪問的問題，影響性能和安全。
pnpm 依賴管理
pnpm 的作者Zoltan Kochan發(fā)現(xiàn) yarn 并沒有打算去解決上述的這些問題，于是另起爐灶，寫了全新的包管理器，開創(chuàng)了一套新的依賴管理機制，現(xiàn)在就讓我們?nèi)ヒ惶骄烤埂?/p>
還是以安裝 express 為例，我們新建一個目錄，執(zhí)行:
- pnpm init -y
然后執(zhí)行:
- pnpm install express
我們再去看看node_modules:
- .pnpm
- .modules.yaml
- express
我們直接就看到了express，但值得注意的是，這里僅僅只是一個軟鏈接，不信你打開看看，里面并沒有 node_modules 目錄，如果是真正的文件位置，那么根據(jù) node 的包加載機制，它是找不到依賴的。那么它真正的位置在哪呢?
我們繼續(xù)在 .pnpm 當中尋找:
- ▾ node_modules
- ▾ .pnpm
- ▸ accepts@1.3.7
- ▸ array-flatten@1.1.1
- ...
- ▾ express@4.17.1
- ▾ node_modules
- ▸ accepts
- ▸ array-flatten
- ▸ body-parser
- ▸ content-disposition
- ...
- ▸ etag
- ▾ express
- ▸ lib
- History.md
- index.js
- LICENSE
- package.json
- Readme.md
好家伙!竟然在 .pnpm/express@4.17.1/node_modules/express下面找到了!
隨便打開一個別的包:
好像也都是一樣的規(guī)律，都是
再看看.pnpm，.pnpm目錄下雖然呈現(xiàn)的是扁平的目錄結構，但仔細想想，順著軟鏈接慢慢展開，其實就是嵌套的結構!
- ▾ node_modules
- ▾ .pnpm
- ▸ accepts@1.3.7
- ▸ array-flatten@1.1.1
- ...
- ▾ express@4.17.1
- ▾ node_modules
- ▸ accepts -> ../accepts@1.3.7/node_modules/accepts
- ▸ array-flatten -> ../array-flatten@1.1.1/node_modules/array-flatten
- ...
- ▾ express
- ▸ lib
- History.md
- index.js
- LICENSE
- package.json
- Readme.md
將包本身和依賴放在同一個node_module下面，與原生 Node 完全兼容，又能將 package 與相關的依賴很好地組織到一起，設計十分精妙。
現(xiàn)在我們回過頭來看，根目錄下的 node_modules 下面不再是眼花繚亂的依賴，而是跟 package.json 聲明的依賴基本保持一致。即使 pnpm 內(nèi)部會有一些包會設置依賴提升，會被提升到根目錄 node_modules 當中，但整體上，根目錄的node_modules比以前還是清晰和規(guī)范了許多。
四、再談安全
不知道你發(fā)現(xiàn)沒有，pnpm 這種依賴管理的方式也很巧妙地規(guī)避了非法訪問依賴的問題，也就是只要一個包未在 package.json 中聲明依賴，那么在項目中是無法訪問的。
但在 npm/yarn 當中是做不到的，那你可能會問了，如果 A 依賴 B， B 依賴 C，那么 A 就算沒有聲明 C 的依賴，由于有依賴提升的存在，C 被裝到了 A 的node_modules里面，那我在 A 里面用 C，跑起來沒有問題呀，我上線了之后，也能正常運行啊。不是挺安全的嗎?
還真不是。
第一，你要知道 B 的版本是可能隨時變化的，假如之前依賴的是C@1.0.1，現(xiàn)在發(fā)了新版，新版本的 B 依賴 C@2.0.1，那么在項目 A 當中 npm/yarn install 之后，裝上的是 2.0.1 版本的 C，而 A 當中用的還是 C 當中舊版的 API，可能就直接報錯了。
第二，如果 B 更新之后，可能不需要 C 了，那么安裝依賴的時候，C 都不會裝到node_modules里面，A 當中引用 C 的代碼直接報錯。
還有一種情況，在 monorepo 項目中，如果 A 依賴 X，B 依賴 X，還有一個 C，它不依賴 X，但它代碼里面用到了 X。由于依賴提升的存在，npm/yarn 會把 X 放到根目錄的 node_modules 中，這樣 C 在本地是能夠跑起來的，因為根據(jù) node 的包加載機制，它能夠加載到 monorepo 項目根目錄下的 node_modules 中的 X。但試想一下，一旦 C 單獨發(fā)包出去，用戶單獨安裝 C，那么就找不到 X 了，執(zhí)行到引用 X 的代碼時就直接報錯了。
這些，都是依賴提升潛在的 bug。如果是自己的業(yè)務代碼還好，試想一下如果是給很多開發(fā)者用的工具包，那危害就非常嚴重了。
npm 也有想過去解決這個問題，指定--global-style參數(shù)即可禁止變量提升，但這樣做相當于回到了當年嵌套依賴的時代，一夜回到解放前，前面提到的嵌套依賴的缺點仍然暴露無遺。
npm/yarn 本身去解決依賴提升的問題貌似很難完成，不過社區(qū)針對這個問題也已經(jīng)有特定的解決方案: dependency-check，地址: https://github.com/dependency-check-team/dependency-check
但不可否認的是，pnpm 做的更加徹底，獨創(chuàng)的一套依賴管理方式不僅解決了依賴提升的安全問題，還大大優(yōu)化了時間和空間上的性能。
五、日常使用
說了這么多，估計你會覺得 pnpm 挺復雜的，是不是用起來成本很高呢?
恰好相反，pnpm 使用起來十分簡單，如果你之前有 npm/yarn 的使用經(jīng)驗，甚至可以無縫遷移到 pnpm 上來。不信我們來舉幾個日常使用的例子。
pnpm install
跟 npm install 類似，安裝項目下所有的依賴。但對于 monorepo 項目，會安裝 workspace 下面所有 packages 的所有依賴。不過可以通過 --filter 參數(shù)來指定 package，只對滿足條件的 package 進行依賴安裝。
當然，也可以這樣使用，來進行單個包的安裝:
- // 安裝 axios
- pnpm install axios
- // 安裝 axios 并將 axios 添加至 devDependencies
- pnpm install axios -D
- // 安裝 axios 并將 axios 添加至 dependencies
- pnpm install axios -S
當然，也可以通過 --filter 來指定 package。
pnpm update
根據(jù)指定的范圍將包更新到最新版本，monorepo 項目中可以通過 --filter 來指定 package。
pnpm uninstall
在 node_modules 和 package.json 中移除指定的依賴。monorepo 項目同上。舉例如下:
- // 移除 axios
- pnpm uninstall axios --filter package-a
pnpm link
將本地項目連接到另一個項目。注意，使用的是硬鏈接，而不是軟鏈接。如:
- pnpm link ../../axios
另外，對于我們經(jīng)常用到npm run/start/test/publish，這些直接換成 pnpm 也是一樣的，不再贅述。更多的使用姿勢可參考官方文檔: https://pnpm.js.org/en/
可以看到，雖然 pnpm 內(nèi)部做了非常多復雜的設計，但實際上對于用戶來說是無感知的，使用起來非常友好。并且，現(xiàn)在作者現(xiàn)在還一直在維護，目前 npm 上周下載量已經(jīng)有 10w +，經(jīng)歷了大規(guī)模用戶的考驗，穩(wěn)定性也能有所保障。
因此，綜合來看，pnpm 是一個相比 npm/yarn 更優(yōu)的方案，期待未來 pnpm 能有更多的落地。
