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，而是为项目中的每个依赖项创建一个带有哈希值的文件
- 尚未做好投入生产环境的准备
…

Js中文网 – 前端进阶资源教程 www.javascriptC.com,typescript 中文文档
一个帮助开发者成长的社区，你想要的，在这里都能找到

哎… 🥵

如我们所见，yarn 发布后，npm 受到启发（并被迫？）开发了许多好的工具和机制。 yarn 因为解决了与 npm 相关的一些重要问题而倍受赞誉，并在 2016 年开始向竞争对手施加压力。包的处理速度、安全性和确定性是必不可少的功能，它们使当今的开发人员能够专注于创造价值，而且并不为这两种工具进行争吵。