npm 和 yarn 你選哪一個？

做者：Charlie Midtlyng

翻譯：瘋狂的技術宅

原文：javascript.christmas/2019/10

未經容許嚴禁轉載

每一個團隊都必須在開發過程當中作出各類決定。其中一般會涉及到 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 年開始向競爭對手施加壓力。包的處理速度、安全性和肯定性是必不可少的功能，它們使當今的開發人員可以專一於創造價值，並且並不爲這兩種工具進行爭吵。

結論 🤔

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

老是有例外嗎？ 🧐

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

pnpm 🥉

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

歡迎關注前端公衆號：前端先鋒，免費領取前端工程化實用工具包。