一文聊聊Node包管理發展的五個階段

從2009 Node 誕生至今，Node 生態發展繁榮，圍繞著 Node 生態衍生出的 Node 套件管理器百花齊放，先後出現了 npm、kpm、pnpm、yarn、cnpm 等等。實際上Node 套件管理器發展主要分5個階段，下面我們一起看下每個階段的關鍵特徵和代表產物吧~

階段一：刀耕火種

正確來說，Node是不存在沒有套件管理器時期的，2009年，Node.js 問世時npm的雛形也發布了。 【相關教學推薦：nodejs影片教學、程式設計教學】

npm 全名為Node.js Package Manager；從A brief history of Node.js 裡面可以看到

2009 
Node.js is born 
The first form of npm is created

下面聊一下沒有出現Node包管理器時期是怎樣的，那時候做的更多的事情就是

• 網上尋找各軟體的官網，如jQuery；

• 找到下載位址，下載zip 套件；

• 解壓縮，放到專案中一個叫libs 的目錄中；

• 想更方便的話，直接將CDN 連結貼到HTML 中

那時候模組化管理？版本號管理？依賴升級？都不存在的！

階段二：嵌套安裝

2009 年，Node.js 誕生，npm的雛形也正在醞釀，2011年發布了1.0 版本；npm是圍繞著語意版本控制semver 的想法而設計的，預設Node包開發者，在升級依賴包自訂版本號時，都會依照semver 規範升級版本號。

代名詞： Node套件管理規範化、node_modules 目錄巢狀存放依賴

代表產物： npm v1、v2 版本

關鍵特點：

（1）依賴套件嵌套安裝，相同版本的依賴會被冗餘安裝

（2）依賴套件安裝不確定性：預設裝最新次版本的依賴套件（可設定固定版本）

（3）序列安裝依賴，速度慢；不支援離線快取

解釋1：依賴 巢狀安裝 ，如果A依賴B、B依賴C，node_modules目錄如下

node_modules
- package-A
-- node_modules
--- package-B
----- node_modules
------ package-C
-------- some-really-really-really-long-file-name-in-package-c.js

問題： 依賴巢狀過多會造成嵌套地獄，同時會出現大量相同依賴套件的冗餘安裝，造成node_modules 體積過大，需要程式設計師定期的rm -rf node_modules，但windows系統，許多程式無法處理超過260個字元的檔案路徑名，早期npm 的windows 用戶都看過這個彈跳窗

---

#解釋2：針對每次npm install 預設安裝最新次版本依賴，造成的依賴安裝 不確定性 問題：

semver 規範了版本編號構成：X.Y.Z-[state]，版本號升級規格如下

• X 是主版本號： API 產生的變化，與舊版本不相容時，升級主版本號
• Y 是次版本號： 增加了新的API，但向後相容，升級次版本號
• Z 是補丁版本號： 當做了向後相容的缺陷修復的時候
• state 可以是：alpha（內測）、beta （公測）、gamma（相當成熟的測試版）、rc（預發布）

版本不確定原因：執行npm 預設安裝依賴指令時，npm 認為開發者都會遵循semver 版本升級規範，直接給開發者安裝了最新次版本的依賴套件

• 解決方案1：可以透過npm config set save-exact true指令關閉在版本號碼前面使用^的預設行為
• 總結：無法解決依賴函式庫自己的依賴預設安裝最新次版本的問題

• 解決方案2：npm提供了shrinkwrap 指令，會產生一個npm-shrinkwrap.json 文件，為所有庫和所有嵌套依賴的庫記錄精準的版本

• 總結：鎖定文件不會預設生成，需要使用者手動執行指令；依賴使用者知道這個指令，相對繁瑣

#階段三：扁平化安裝

2015年，為解決npm1、npm2 存在的巢狀安裝、版本不規定問題，完全重寫了npm 程式

代名詞： 較少冗餘依賴的安裝、node_modules 目錄扁平化存放依賴

代表產物： npm v3版本

原理簡述： npm install時，先建構依賴樹再將所有依賴都安裝在node_modules 根目錄，子依賴遇到不同版本的重名依賴時，會將子依賴安裝在自己node_modules下

關鍵特點：

（1）減少冗餘安裝：依賴扁平化安裝，在一定情況下減少了冗餘套件的安裝

存在的問題：

（1）「幽靈依賴」、「幻影依賴」 問題

（2）「雙胞胎陌生人」 、「依賴套件分身」 問題

（3）目錄不固定：依賴的安裝順序，決定了node_module 目錄結構

解釋1：依賴的依序安裝順序，決定了node_modules 目錄結構

如下場景： App1 都依賴packageA 和packageC 和packageG 和packageH，而packageA 和packageC 都依賴了packageB v1.0，packageG、packageH 都依賴packageB 的v2.0 版本

如果先安裝packageA 或packageC，node_modules 目錄如下

如果先安裝packageG 或packageH，node_modules 目錄如下

#針對如上情況，npm 提供了指令npm dedupe，可以手動整理&簡化node_modules 的目錄結構，整理後的node_modules 目錄結構是一致的，不受依賴套件安裝順序影響

解釋2：不一定能減少冗餘套件的安裝

透過舉例1，可以看出雖然依賴套件扁平化安裝，但仍存在相同版本的依賴包，有冗餘包

解釋3：「雙胞胎陌生人」 問題

參考範例1中，相同版本的依賴包，被安裝兩次，被放置到兩處，這種現像被稱為“雙胞胎陌生人”

解釋4：“幽靈依賴” 問題

node_modules 一級目錄下的依賴包，開發者可以直接使用，但依賴包沒定義在package.json 中，這樣的依賴包被稱為“幽靈依賴”，前端項目中使用“幽靈依賴”，後期可能會出現問題。

因為後期可能伴隨著其他依賴的升級移除了這個“幽靈依賴”，此時node_modules 中就不存在了，執行npm install 時，並不會主觀的去安裝“幽靈依賴”，導致項目找不到依賴包，然後報錯。

階段四：安全、加速

2016年，yarn、pnpm release 版本相繼出現，在一定程度上解決了先前的安裝版本不確定、安裝速度慢等問題，yarn 率先推出的能力相比於npm，更奪人眼球，保證了一致性&安全性，提升了安裝速度

代名詞： 依賴安裝相對安全、加速

代表產物： yarn release版本、pnpm release版本、npm v5 版本（npm v4沒有太大變化，v5向前邁了一大步）

關鍵特點：

（1）安全性：預設產生版本鎖定文件，保證了每次安裝依賴版本都一樣

（2）提速：增加了快取離線安裝、並行安裝、安裝異常後自動重試

（3）workspace：yarn從v1版本開始支持，可以高效管理多個專案的依賴套件；npm v7才支援workspace

• #存在的問題

：

（1）幽靈依賴

（2）依賴套件單項目重複安裝、跨項目重複安裝

（3）目錄不固定：依賴的安裝順序，決定了node_module 目錄結構

解釋1：關於安全性

yarn v0.x 版本率先、npm v5.x 版本緊跟其後，下載依賴時，預設產生依賴鎖定文件，精確地將版本鎖定在一個值

yarn 的.lock 文件：只是記錄安裝的依賴版本，需要結合package.json 來確定node_modules 目錄結構npm 的.lock 檔案：記錄了安裝的依賴版本及node_modules 目錄結構

總結： 避免了不同終端安裝依賴時版本不一致問題，但「依賴幽靈」 問題仍然存在

解釋2：關於提速- 離線緩存

######npm v2版本就支援了緩存，但需要聯網檢測，才能使用快取的依賴######yarn v0.x版本率先支援了離線緩存，從網路下載的套件都會快取到全域，下次安裝優先從本地找，找到直接copy###### npm v5版本重寫了快取系統，也支援了離線安裝，安裝速度大大提升#########解釋3：關於提速- 並行安裝#########yarn 率先支援了依賴套件並行安裝，先前npm 序列安裝依賴，後來npm 也優化了並行安裝##########解釋4：安裝依賴後，自動整理node_modules 目錄##########起始時間：yarn v1.x 版本、npm v4.x 版本###

• 如果專案中刪除了.lock 文件，初始化安裝依賴時，會自動整理node_modules 目錄；npm v4.x之前版本，需要使用者手動執行指令npm dedupe整理依賴目錄
• 由於node_modules 是扁平化管理依賴，深層依賴可能會被安裝到一級目錄下；當專案中再安裝不同版本的依賴時，遇到依賴版本衝突，會自動將深層依賴從一級目錄移到父依賴目錄下【已驗證】

#階段五：更安全、高速、低耗

對著pnpm 的成熟，開發者們享受著pnpm 帶來的更安全、更高速、儲存更低耗等紅利，解決了「幽靈依賴」 問題，解決了重複依賴問題

代名詞： 安全性（依賴安裝所見即所得）、高速（不重複安裝）、儲存低耗（硬連結軟連結）

代表產物： pnpm

關鍵特點：

（1）速度極快：儲存中心集中管理依賴，直接硬連結到專案的在 node_modules/.pnpm 中。相較於先前的工作方式，減少了從全域node_modules copy 到專案內的大量IO 操作

（2）磁碟利用率極高：

• #跨專案共用相同版本的依賴：硬連結、軟連結
• 最大限度的複用相同依賴的不同版本：只增加儲存不同版本的Diff 檔案

（3 ）安全性高：node_modules 目錄結構就是package.json 依賴列表，解決了「幽靈依賴」問題

效能表現如下：

更多node相關知識，請造訪：nodejs 教學！

以上是一文聊聊Node包管理發展的五個階段的詳細內容。更多資訊請關注PHP中文網其他相關文章！