npm
cnpm
pnpm
yarn
npx

各位 V 友们，你们在使用包管理工具有什么使用优先级吗？它们的区别是什么？作为一个后端，有时候会做一些前端开发，会纠结这些。虽然是瞎纠结，但还是想听各位 V 友们讲讲。

Mac 开发 fnm + node + pnpm 是不是现在的最佳选择？

pnpm ，省硬盘空间

node>20 pnpm 低于 20 用 cnpm

npm ，硬盘就是大😎

yarn ，不知道为什么，觉得它好用，我不是前端，我是后端

pnpm/yarn,看版本

pnpm or bun

习惯用 yarn 了

npm yarn

pnpm

npx 不是包管理，是执行包脚本的

除了节省空间，pnpm 的 workspace 、patch 管理都挺好用，不用额外安装其他东西

pnpm 速度快很多。缺点就是改 node_modules 里的代码不太方便

npx 跟其它的不是一类东西
yarn 对现在的 npm 没有明显优势
cnpm 绝对不要用
npm 和 pnpm 选一个

用 npm 和 yarn 的遇到幽灵依赖就老实了😏

作为一个后端，我一般都是挨个试试，不行就删掉那个文件夹再换一个跑...

npx 是脚手架

不用 pnpm 的都 gck

钟爱 npm
因为比 yarn 和 pnpm 都少了一个字母😏

npx 也不是脚手架……是执行 npm 包脚本的

pnpm + fnm

公司项目 pnpm
个人项目 bun

volta 代替 fnm

pnpm

npm
后面想试试 bun

pnpm 更现代，没有幻影依赖，能用 pnpm 就别考虑别的了吧

pnpm 或者 npm
yarn 我看大家都是 1.22 版本，但是现在已经 4.x 了，对比 npm 10 没啥优势，对 peer-dependences 默认是不处理
yarn 2.0 以上又没有 node_module 大部分人都不会用

pnpm

我是后端，一开始用 npm ，后来用 yarn （感觉出现依赖问题相对 npm 少），现在用 pnpm ，install 非常快

yarn

npm 没什么问题，如果你遇到特定的问题就换其他的包管理器，遇不到 npm 就行了

npm, 主要是自带直接用, 方便.

稳定实用选 pnpm ，拥抱新技术选 bun

yarn 或者 npm

npm
P.S. npm 和 npx 不算同一个吗

pnpm

npm: 我一直用这个,因为是默认,既然是默认,稳定性总比其他好吧。
npm: 以前没代理才用他,有些包还是有网络问题的。后面一直代理,省心省事,速度可能还更快(用的 40 ￥/月的机场)。
pnpm: 只是听说过,似乎是 vue3 之后才有的
yarn: 用过几次,我都不知道他和 npm 区别。
npx: 需要多个 node 版本,才需要用。

老项目 npm/yarn

新项目 pnpm 省硬盘

不知道是不是错觉，感觉 yarn 在一些项目里兼容性比较强？反正有几个老项目使用 npm 安装就一堆报错，删掉 node_modules 使用 yarn 安装就可以……

都用过，现在只用 npm 。

原因是不折腾、硬盘大、命令用不了几次。

npm 、pnpm

pnpm 或 bun

人生苦短，npm 。

porn 和 hub

fnm+pnpm or bun

yarn / pnpm ，每个项目会配置对应的 packageManager ，配合开启 corepack 使用

npm 主打就是一个不折腾

用 pnpm 吧！ pnpm 本身还可以管理 nodejs 版本，这样可以舍弃 fnm 了

人生苦短，pnpm

fnm 比 nvm 好用吗？

bun 一把梭

yarn

目前在用 bun 、volta

老项目/第三方模版框架 npm ，新项目毫无疑问 pnpm

yarn@1, pnpm

yarn/pnpm

没有人觉得 pnpm 在键盘位置上的分布感觉敲起来很费力吗😓

pnpm

pnpm 虽然省空间，但是 yarn 更好用

1. npm - 简单高效, 保持最新版本, 支持 workspace 也能解决一些对等依赖的问题, 前提是要保持 node 最新版本才好用

2. cnpm - 只是为了解决国内代理的问题, 这没必要了把?
3. pnpm - 为了解决 node_modules 占用磁盘的问题, 同样也有 workspace 等等一些功能, 中规中矩
4. yarn - 历史上最好用的包管理工具, 独特的 Plug'n'Play 模式, 并且完全解决 node_modules 所有的缺点. 缺点是不兼容目前大部分的国产框架, 例如 dumi 等等, 并且使用起来复杂, 需要安装额外的工具, 学习成本高

要是我, 可能 yarn 的 Plug'n'Play 最为第一公民

新项目 pnpm
老项目 yarn ，谁用谁知道，跑老项目版本问题能卡你好几天，换成 yarn 一次成功

改个别名，官方文档推荐改成 pn

赞成大多数人说的，低版本/老项目就 yarn ，node 版本比较新就 pnpm 。 如果只选一个，那我推荐 yarn

自己玩 pnpm

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

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

bun 呢？

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

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

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

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

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

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

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

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

pnpm / bun

bun only

npm pnpm

打补丁

＃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 也没准

参照地址

• yarnpkg.com/blog/release/2.0

• github.com/pnpm/pnpm/pull/2908

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

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

  ＃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

＃71
如果是 Yarn 安装的项目, 则 100 年以后 仍然可以用 Yarn 进启动, 哪怕是互联网已经完全断开, 或者说没有任何第三方 npm 的镜像库, 以及 npm 库 Yarn 一样可以启动, 这样就极大的避免了 100 年以后的项目无法启动的问题

你是没有使用 Yarn 的 Zero-installs 来安装项目, 何谈 10 年后进行启动? Yarn 的 Zero-installs 就是为了解决你所谓的 10 年后无法启动的问题

其次 Yarn 重写 node_modules 加载的方式, 这些不用考虑肯定提升了性能

以前的目录是

• a

  • esm
  • packages.json

• b

  • esm
  • packages.json

这样的接口, 是可以可以展开的文件夹

而现在变成了

[email&＃160;protected]
[email&＃160;protected]
至于性能提高多少, 相信你只要是用过电脑的都知道 copy 一个 1g 的文件, 和 copy 一个一共 1g 的散文件的文件速度.
优化的效率就在这个地方, 因此所以需要添加 .pnp.cjs 和 .pnp.loader.mjs来解决这个问题, 应该 node 本身不支持.
pnpm 只是软连接, 这并没有解决什么问题, 而 yarn 是彻底重构 npm 这是本质区别.
yarn 不合适初学者, 因为会有很多问题. 这些初学者的问题都解决了, 那么你将会打开一个新的世界, 至少无论压缩体积,还是删除效率还是安装效率至少加快了百分之八十, 甚至一些对等依赖的问题也直接提示给我了.
Yarn 安全可靠速度快, 没有哪个包管理器目前能做到 Yarn 的这些功能.
当然大多数人不会在乎现在的项目是否 10 年能启动起来

参照链接

• yarnpkg.com/features/caching

  ＃74 为什么把 Yarn 作为第一公民, 因为 Yarn 的 PnP 这一定是未来, 所谓的其他项目不支持,这是改变必须要尽力的过程, 总不能为升级需要变化, 所以一直使用 JDK 8 ? 改变就是好事, 积极拥抱改变才是正道

  ＃74 这个是真实的性能测试结果

  yarnpkg.com/features/performances