一文聊聊Node包管理髮展的五個階段
階段一：刀耕火種
正確來說，Node是不存在沒有包管理器時期的，2009年，Node.js 問世時 npm的雛形也釋出了。【相關教學推薦：、】
npm 全稱 Node.js Package Manager；從 裡面可以看到
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相關知識，請存取：！
以上就是一文聊聊Node包管理髮展的五個階段的詳細內容，更多請關注TW511.COM其它相關文章！