每个团队都必须在开发过程中做出各种决定。其中通常会涉及到 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
成熟,也不能投入生产环境。