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 成熟，也不能投入生产环境。

欢迎关注前端公众号：前端先锋，免费领取前端工程化实用工具包。