@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 作为一个特性并没有被完善的定义？或者说至少它完全不是像你说的所谓“独特的”特性。