從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]，版本號升級規格如下
版本不確定原因：執行npm 預設安裝依賴指令時，npm 認為開發者都會遵循semver 版本升級規範，直接給開發者安裝了最新次版本的依賴套件
解決方案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整理依賴目錄對著pnpm 的成熟，開發者們享受著pnpm 帶來的更安全、更高速、儲存更低耗等紅利，解決了「幽靈依賴」 問題，解決了重複依賴問題
代名詞： 安全性（依賴安裝所見即所得）、高速（不重複安裝）、儲存低耗（硬連結軟連結）
代表產物： pnpm
關鍵特點：
（1）速度極快：儲存中心集中管理依賴，直接硬連結到專案的在 node_modules/.pnpm 中。相較於先前的工作方式，減少了從全域node_modules copy 到專案內的大量IO 操作
（2）磁碟利用率極高：
（3 ）安全性高：node_modules 目錄結構就是package.json 依賴列表，解決了「幽靈依賴」問題
效能表現如下：
更多node相關知識，請造訪：nodejs 教學！
以上是一文聊聊Node包管理發展的五個階段的詳細內容。更多資訊請關注PHP中文網其他相關文章！
