一文聊聊Node包管理發展的五個階段-js教程-PHP中文網

從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 是扁平化管理依賴，深層依賴可能會被安裝到一級目錄下；當專案中再安裝不同版本的依賴時，遇到依賴版本衝突，會自動將深層依賴從一級目錄移到父依賴目錄下【已驗證】