本文小編為大家詳細介紹“Node包管理發(fā)展的階段有哪些”，內(nèi)容詳細，步驟清晰，細節(jié)處理妥當，希望這篇“Node包管理發(fā)展的階段有哪些”文章能幫助大家解決疑惑，下面跟著小編的思路慢慢深入，一起來學習新知識吧。
創(chuàng)新互聯(lián)是一家專業(yè)提供青原企業(yè)網(wǎng)站建設(shè),專注與成都網(wǎng)站設(shè)計、網(wǎng)站制作、H5場景定制、小程序制作等業(yè)務(wù)。10年已為青原眾多企業(yè)、政府機構(gòu)等服務(wù)。創(chuàng)新互聯(lián)專業(yè)網(wǎng)站設(shè)計公司優(yōu)惠進行中。
正確來說，Node是不存在沒有包管理器時期的，2009年，Node.js 問世時 npm的雛形也發(fā)布了。
npm 全稱 Node.js Package Manager；從A brief history of Node.js 里面可以看到
2009
Node.js is born
The first form of npm is created
下面聊一下沒有出現(xiàn)Node包管理器時期是怎樣的，那時候做的更多的事情就是
網(wǎng)上尋找各軟件的官網(wǎng)，比如 jQuery；
找到下載地址，下載 zip 包；
解壓，放到項目中一個叫 libs 的目錄中；
想更方便的話，直接將 cdn 鏈接粘貼到 HTML 中
那時候 模塊化管理？版本號管理？依賴升級？都不存在的！
2009 年，Node.js 誕生，npm的雛形也正在醞釀，2011年發(fā)布了 1.0 版本；npm是圍繞著語義版本控制 semver 的思想而設(shè)計的，默認認為Node包開發(fā)者，在升級依賴包自定義版本號時，都會按照 semver 規(guī)范升級版本號。
代名詞：Node包管理規(guī)范化、node_modules 目錄嵌套存放依賴
代表產(chǎn)物：npm v1、v2 版本
關(guān)鍵特點：
（1）依賴包嵌套安裝，相同版本的依賴會被冗余安裝
（2）依賴包安裝不確定性：默認裝最新次版本的依賴包（可設(shè)置固定版本）
（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
問題：依賴嵌套過多會造成嵌套地獄，與此同時會出現(xiàn)大量相同依賴包的冗余安裝，造成 node_modules 體積過大，需要程序員定期的 rm -rf node_modules，但windows系統(tǒng)，很多程序無法處理超過260個字符的文件路徑名，早期 npm 的 windows 用戶都見過這個彈窗
解釋2：針對每次 npm install 默認安裝最新次版本依賴，造成的依賴安裝不確定性問題：
semver 規(guī)范了版本號構(gòu)成：X.Y.Z-[state]，版本號升級規(guī)范如下
X 是主版本號： API 產(chǎn)生的變化，與舊版本不兼容時，升級主版本號
Y 是次版本號： 增加了新的API，但向后兼容，升級次版本號
Z 是補丁版本號： 當做了向后兼容的缺陷修復(fù)的時候
state 可以是：alpha（內(nèi)測）、beta（公測）、gamma（相當成熟的測試版）、rc（預(yù)發(fā)布）
版本不確定原因：執(zhí)行 npm 默認安裝依賴指令時，npm 認為開發(fā)者都會遵循 semver 版本升級規(guī)范，直接給開發(fā)者安裝 了最新次版本的依賴包
解決方案1：可以通過npm config set save-exact true命令關(guān)閉在版本號前面使用 ^的默認行為
總結(jié)：無法解決依賴庫自己的依賴默認安裝最新次版本的問題
解決方案2：npm提供了 shrinkwrap 命令，會生成一個 npm-shrinkwrap.json 文件，為所有庫和所有嵌套依賴的庫記錄精準的版本
總結(jié)：鎖文件不會默認生成，需要用戶手動執(zhí)行指令；依賴于用戶知道這個指令，相對繁瑣
2015年，為解決 npm1、npm2 存在的 嵌套安裝、版本不規(guī)定問題，完全重寫了 npm 程序
代名詞：較少冗余依賴的安裝、node_modules 目錄扁平化存放依賴
代表產(chǎn)物：npm v3版本
原理簡述：npm install時，先構(gòu)建依賴樹再將所有依賴都安裝在 node_modules 根目錄，子依賴遇到不同版本的重名依賴時，會將子依賴安裝在自己node_modules下
關(guān)鍵特點：
（1）減少冗余安裝：依賴扁平化安裝，一定情況下減少了冗余包的安裝
存在的問題：
（1）“幽靈依賴”、“幻影依賴” 問題
（2）“雙胞胎陌生人” 、“依賴包分身” 問題
（3）目錄不固定：依賴的安裝順序，決定了 node_module 目錄結(jié)構(gòu)
解釋1：依賴的依次安裝順序，決定了node_modules 目錄結(jié)構(gòu)
如下場景：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 的目錄結(jié)構(gòu)，整理后的 node_modules 目錄結(jié)構(gòu)是一致的，不受依賴包安裝順序影響
解釋2：不一定能減少冗余包的安裝
通過舉例1，可以看出雖然依賴包扁平化安裝，但仍存在相同版本的依賴包，有冗余包
解釋3：“雙胞胎陌生人” 問題
參考舉例1中，相同版本的依賴包，被安裝兩次，被放置到兩處，這種現(xiàn)象被稱為“雙胞胎陌生人”
解釋4：“幽靈依賴” 問題
node_modules 一級目錄下的依賴包，開發(fā)者可以直接使用，但依賴包沒定義在 package.json 中，這樣的依賴包被稱為 “幽靈依賴”，前端項目中使用 “幽靈依賴”，后期可能會出現(xiàn)問題。
因為后期可能伴隨著 其他依賴的升級移除了這個“幽靈依賴”，此時 node_modules 中就不存在了，執(zhí)行 npm install 時，并不會主觀的去安裝 “幽靈依賴”，導(dǎo)致項目找不到依賴包，然后報錯。
2016年，yarn、pnpm release 版本相繼出現(xiàn)，在一定程度上解決了之前的 安裝版本不確定、安裝速度慢等問題，yarn 率先推出的能力相比于 npm，更奪人眼球，保證了一致性&安全性，提升了安裝速度
代名詞：依賴安裝相對安全、提速
代表產(chǎn)物：yarn release版本、pnpm release版本、npm v5 版本（npm v4沒有太大變化，v5向前邁了一大步）
關(guān)鍵特點：
（1）安全：默認生成版本鎖文件，保證了每次安裝依賴版本都一樣
（2）提速：增加了緩存離線安裝、并行安裝、安裝異常后自動重試
（3）workspace：yarn從v1版本開始支持，可以高效管理多個項目的依賴包；npm v7才支持 workspace
存在的問題：
（1）幽靈依賴
（2）依賴包單項目重復(fù)安裝、跨項目重復(fù)安裝
（3）目錄不固定：依賴的安裝順序，決定了 node_module 目錄結(jié)構(gòu)
解釋1：關(guān)于安全
yarn v0.x 版本率先、npm v5.x 版本緊跟其后，下載依賴時，默認生成 依賴鎖文件，精確地將版本鎖定在一個值
yarn 的 .lock 文件：只是記錄安裝的依賴版本，需要結(jié)合 package.json 來確定 node_modules 目錄結(jié)構(gòu)
npm 的 .lock 文件：記錄了安裝的依賴版本 及 node_modules 目錄結(jié)構(gòu)
總結(jié)：避免了不同終端安裝依賴時版本不一致問題，但“依賴幽靈” 問題仍然存在
解釋2：關(guān)于提速 - 離線緩存
npm v2版本 就支持了緩存，但需要聯(lián)網(wǎng)檢測，才能使用 緩存的依賴
yarn v0.x版本 率先支持了 離線緩存，從網(wǎng)絡(luò)下載的包都會緩存到全局，下次安裝優(yōu)先從本地找，找到直接copy
npm v5版本 重寫了緩存系統(tǒng)，也支持了離線安裝，安裝速度大大提升
解釋3：關(guān)于提速 - 并行安裝
yarn 率先支持了依賴包并行安裝，此前 npm 串行安裝依賴，后來 npm 也優(yōu)化了并行安裝
解釋4：安裝依賴后，自動整理 node_modules 目錄
起始時間：yarn v1.x 版本、npm v4.x 版本
如果項目中刪除了 .lock 文件，初始化安裝依賴時，會自動整理 node_modules 目錄；npm v4.x之前版本，需要用戶手動執(zhí)行指令 npm dedupe整理依賴目錄
由于 node_modules 是扁平化管理依賴，深層依賴可能會被安裝到一級目錄下；當項目中再安裝不同版本的依賴時，遇到依賴版本沖突，會自動將深層依賴從一級目錄移動到父依賴目錄下 【已驗證】
對著 pnpm 的成熟，開發(fā)者們享受著 pnpm 帶來的 更安全、更高速、存儲更低耗 等紅利，解決了“幽靈依賴” 問題，解決了重復(fù)依賴問題
代名詞：安全（依賴安裝所見即所得）、高速（不重復(fù)安裝）、存儲低耗（硬鏈接 + 軟鏈接）
代表產(chǎn)物：pnpm
關(guān)鍵特點：
（1）速度極快：存儲中心集中管理依賴，直接硬鏈接到項目的 node_modules/.pnpm 中。相比于之前的工作方式，減少了從全局 node_modules copy 到項目內(nèi)的大量 IO 操作
（2）磁盤利用率極高：
跨項目共用相同版本的依賴：硬鏈接、軟鏈接
最大限度的復(fù)用同一依賴的不同版本：只增加存儲不同版本的 Diff 文件
（3）安全性高：node_modules 目錄結(jié)構(gòu)就是 package.json 依賴列表，解決了 “幽靈依賴” 問題
性能表現(xiàn)如下：
讀到這里，這篇“Node包管理發(fā)展的階段有哪些”文章已經(jīng)介紹完畢，想要掌握這篇文章的知識點還需要大家自己動手實踐使用過才能領(lǐng)會，如果想了解更多相關(guān)內(nèi)容的文章，歡迎關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道。
重慶分公司
重慶分公司
