npm 和 yarn 你選哪個？

每個團隊都必須在開發過程中做出各種決定。其中通常會涉及到 yarn，npm 或其它用於構建和打包 JavaScript 代碼的工具。一些開發人員渴望朝着某個方向前進，有時他們會花費大量時間來嘗試，去做出實際上對他們的工作幾乎沒有什么影響的決策。

首先，要了解為什么要做出一個有趣的決定，我們需要看一下 JavaScript 中包管理的歷史。

 

npm 出現之前：前端依賴項是保存到存儲庫中並手動下載的

2010：npm 發布並支持 nodejs

2012：npm 的使用量急劇增加——主要是由於 Browserifys 瀏覽器的支持

2012：npm 有了一個競爭對手 bower，它完全支持瀏覽器 2012-2016：前端項目的依賴項數量成倍增加

2012-2016：構建和安裝前端應用變得越來越慢

2012-2016：大量（重復的）依賴項存儲在神奇的 node_modules 內的嵌套文件夾中☢️ 2012-2016：rm -rf node_modules 成為前端開發人員最常用的命令。 

2015：bower 輸給了 npm 

2015：node_modules 被修改為扁平化的文件結構！ 

2016： left-pad成為當時的新聞頭條 

2016： yarn 發布

支持 npm 和 bower 倉庫yarn.lock 能夠鎖定安裝的版本並提供確定性的依賴關系。不再 rm -rf node_modules！yarn install 花費的時間是 npm install 的一半（不使用緩存的前提下）緩存和脫機模式使構建過程幾乎不花費時間

2016：npm 發布 shrinkwrap

嘗試處理依賴項鎖定不幸的是，一些錯誤和超出其管理能力的承諾導致該工具的聲譽下降

2017：npm 5 發布

package-lock.json 是他們的新工具，shrinkwrap 被放在一邊package-lock.json 開始與 yarns 鎖定文件競爭

2018：npm ci 發布

直接用 package-lock.json 構建代碼沒有代價高昂的依賴項安全性分析和版本分析大大減少了在構建服務器上的構建時間！

2018：npm 6 發布

npm 檢查要安裝的依賴項中的安全漏洞yarn 和 npm 的構建時間不再有顯差異

2019：tink 開始進入 beta 模式

避免使用 node_modules，而是為項目中的每個依賴項創建一個帶有哈希值的文件尚未做好投入生產環境的准備...

哎... 

如我們所見，yarn 發布后，npm 受到啟發（並被迫？）開發了許多好的工具和機制。 yarn 因為解決了與 npm 相關的一些重要問題而倍受贊譽，並在 2016 年開始向競爭對手施加壓力。包的處理速度、安全性和確定性是必不可少的功能，它們使當今的開發人員能夠專注於創造價值，而且並不為這兩種工具進行爭吵。

廣州設計公司https://www.houdianzi.com 我的007辦公資源網站https://www.wode007.com

結論 

為了方便起見，我建議大多數團隊（必須做出許多其他更重要的技術決定）選擇最簡單的選項 —— npm。它隨 node 一起提供，目前能以足夠好的方式處理包管理。

 

總是有例外嗎？ 

當使用 monorepo 時，yarn workspaces 是一種流行的替代方案，而 npm 則沒有提供等效的替代方法。 lerna 是一個軟件包，它還支持 monorepos 的使用，並且可以與 npm 和 yarn（帶有 workspaces）一起使用。

 

pnpm 

PS：應該提到的是， pnpm 是包管理器的第三種選擇。如果 pnpm 的賣點是如果包已經下載到本地的一個存儲庫中，則它就不會再次下載了——這類似於 Java 中的 maven 依賴管理。在撰寫本文時，pnpm 還不如 yarn 或 npm 成熟，也不能投入生產環境。