前端包管理工具调研

自己玩 pnpm

公司项目 yarn/npm 这俩基本都会用，vue 偏向 npm ，react 偏向 yarn

npx 不是包管理器（它是包管理器的管理器），然后 yarn 最习惯，不为别的，敲这四个字母手指在键盘上移动的最少

bun 呢？

@qrobot #57 不是，你说了这么多缺点，那是怎么得出来它是历史上最好用的包管理工具的结论的？

另外 pnpm 老早就支持 PnP 了，但是目前我还真没见多少人给出这个模式到底解决了什么问题，产生了什么独特的优势，甚至其实就像你说的，它反而还很容易产生新的问题。

再一个我司 10 年前就重度使用 yarn 了，讲真，用了几年后真的不想再用了。yarn 的报错体系非常糟糕，兼容性在彼时也问题多多，出现的一些诡异问题，在社区是很难得到有效支持的，彼时 yarn 的理念导致了很多功能需要你自行处理，社区对此也很无奈。

直到 pnpm 出来之后，我才发现社区也能做出好的包管理器，功能上它愿意往前多走一步，从社区的角度来说他们也没有什么非常苛刻的离奇的理念，来阻止或者说避免去开发某一个功能。和 yarn 比，yarn 已经显得裹脚布了。

再一个 yarn 最大的问题是从 classic 到 v2 的变更，花费了过长的时间，同时还约等于交出了一张白卷。除了 PnP 基本没有交出什么像样的产品特性。

你现在去看 yarn 对 PnP 的介绍，你都没法理解它说的几点优点到底哪里算是优点。甚至介绍文档的最后还要极力劝解你：哎呀我们这个 PnP 真的不复杂，没事的，你试试吧。真的就让人很无语。

@skiy #63 bun 支持的特性有缺失，不建议投入生产。

yarn pnp 零安装 模式，硬盘不值钱

pnpm / bun

bun only

npm pnpm

@Torpedo 打补丁

@shunia #64 yarn 的 pnp 是一个跨时代意义的变化, 至少 yarn 2 (2020 年 1 月), 之后 pnpm(202 年 9 月) 才加入了 PnP 进行支持. Yarn 解决一个最大的问题就是文件碎片的问题, 过多的 node_modules 包会导致庞大的文件碎片, 操作系统在处理这些文件碎片的时候, 这无疑性能损失是非常巨大的.

我自己做的新框架就是采用 Plug'n'Play 作为第一公民, 解决了我很多问题, 例如常见的 peerDependencies 的问题, resolutions 问题, 我很早就开始使用 npm, 如果不是因为 npm 怠惰, 连基本的 workspace 和 overrides 都没有.


至于我说的 "不兼容目前大部分的国产框架", 这本身不是 Yarn 的错误, 而是其他框架没有进行适配, 人不可能一成不变把?


为了让 Yarn 的 Plug'n'Play 作为第一公民, 我重写 umi, 以及 dumi 还有 father 等构建工具, 将 esmodule 和 Plug'n'Play 作为第一公民我觉得是非常必要的, 前端在发展最终 esmodule 和 pnp 这是必然的结局, 或许几年后 yarn 可能推动 npm 做出改变, 然后 npm 默认就支持 pnp 也没准



参照地址

- https://yarnpkg.com/blog/release/2.0
- https://github.com/pnpm/pnpm/pull/2908

@shunia #64 我别的工具使用的少, 目前常用的就是 npm/yarn, 新项目用 yarn, 老项目用 npm. yarn 稳定可靠, 至少不会出现 10 年前的项目, 十年后就跑不起来, 也至少不会经常在内网环境各种依赖下载的问题. 也不会遇到类似于 fakerjs 这种供应链攻击

不用想那么多，轻度用户就用 npm ，重度用户就用 pnpm

@qrobot #71
首先你把 pnpm 完全过滤掉了，根本没提及，说明你没用过？那么什么所谓把 yarn 当作一等公民的比较就是不公平的。

其次请帮忙解释一下 pnp 究竟是如何解决各种 dependecies 相关的问题的，以及它是如何避免操作系统处理文件碎片的问题的。第一个依赖相关的问题，即便是在解决这类问题最激进的 pnpm 项目里，也没有完全解决相关的所有问题。第二个文件碎片的问题，我不知道是你表达错误还是怎样，我不理解的是文件总数不变的情况下，它怎么解决了这个性能损失的。pnpm 增加了硬链接，肯定增加了额外的性能损耗，但是有数据支撑 PnP 比 pnpm 的硬链接提升了多少性能吗？提升的是什么样的性能？在多大的项目里会产生决定性的变化？

即便 npm 哪一天默认支持 PnP ，那也只是一个特性而已，就好比 pnpm 支持 worksapce 的时候也只是一个特性，没有什么所谓的公民一说，其他更上层的工具链在当时也能做好 workspace 管理，反而是 pnpm 的 workspace 确实做的很好，所以下游的上层工具才纷纷接入和支持此一特性。yarn 的 PnP 呢，我的天老爷，提出来多少年了，哪个项目建议你用 PnP 模式运行了？

最后，yarn 的稳定可靠是依赖于 dependencies 本身不作妖，不是 yarn 的功劳。老项目跑不起来只有一种可能，依赖链断裂，这种情况，yarn 处理不了，npm 、pnpm 也处理不了，不存在 yarn 能做好这件事这么一说。你可能没跑过 10 年前的项目，不好意思我跑过，yarn 也搞不定。你对这个问题的理解我觉得有问题。

请多使用事实来说明问题。比如我就知道 pnpm 是很早就支持了 PnP 的，差那两年有没有可能是因为 PnP 作为一个特性并没有被完善的定义？或者说至少它完全不是像你说的所谓“独特的”特性。

pnpm 党+1 ，另外要注意 win 和 linux 环境中运行会有一点差别，比如文件名大小写

monorepo 首选 pnpm ，其他家都还没实现 catalogs 功能吧，等于目前 pnpm 独占，缺点是默认全部重新获取包信息，哪怕前后脚。
bun 是默认离线，快很多，但我一直没找到 bun 怎么启用非扁平 node_modules 结构。此外 bun 不作为包管理器也可以作为运行时使用（不过生产还是不太稳定，1.2.5 遇到了个发布包登陆 npm 无效的 bug ）

不用选，用 pnpm 就行了，可以理解为别的几个（除了 npx ）都是已经/即将被淘汰的包管理解决方案，ps：npx 和别的几个不是一个维度的东西

全部不用，只用 bun

一些老的依赖只能用 yarn ，用 pnpm 多多少少会有点问题

pnpm