@shunia 你看下面的说明. performance 图标上 pnpm 是最快的, 但是下面文字里面也有说明


Yarn 在 add 和 remove 命令的时候, 速度比 pnpm 快

Yarn 在新机器上的时候 install 慢于 pnpm , 因为要执行一系列的安全检查

打包成为 zip 只是为了优化系统对零碎的文件的处理效率, 这个为什么性能变好, 就看各个磁盘怎么处理了.

例如 FAT16,FAT32,NTFS,exFAT 等 window 下的磁盘格式肯定效率 zip 比 node_modules 好, 在说了作为一个库, 这样是不是也方便迁移?

@shunia #74 这个是真实的性能测试结果


https://yarnpkg.com/features/performances

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

@shunia #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 protected]
[email protected]


至于性能提高多少, 相信你只要是用过电脑的都知道 copy 一个 1g 的文件, 和 copy 一个一共 1g 的散文件的文件速度.

优化的效率就在这个地方, 因此所以需要添加 `.pnp.cjs` 和 `.pnp.loader.mjs`来解决这个问题, 应该 node 本身不支持.


pnpm 只是软连接, 这并没有解决什么问题, 而 yarn 是彻底重构 npm 这是本质区别.


yarn 不合适初学者, 因为会有很多问题. 这些初学者的问题都解决了, 那么你将会打开一个新的世界, 至少无论压缩体积,还是删除效率还是安装效率至少加快了百分之八十, 甚至一些对等依赖的问题也直接提示给我了.

Yarn 安全可靠速度快, 没有哪个包管理器目前能做到 Yarn 的这些功能.

当然大多数人不会在乎现在的项目是否 10 年能启动起来

参照链接

- https://yarnpkg.com/features/caching

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

@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

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


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

请问哪些人研发水平能力强, 还需要找工作?

1. 学历低
2. 身体障碍
3. 情商低, 沟通费劲
4. 家境困难

@collery 试试专科以下, 最好是那种中专, 或者辍学的那种, 然后工作经验 2 年-5 年左右. 你招到的绝对是精英

你自己想想啊, 薪资 15-20K, 而且还要全日制本科. 能力好的为何不进大公司, 本身学历就在, 那剩下愿意投简历招牌的, 无法就是哪些不爱好技术, 只是为了上班 CURD 怎么可能技术好. 当然水平一言难尽啊

@jellyX 请问你给我纸巾吗? 还是说街上都有可以指定的纸巾领取点

以前我经常随便丢垃圾, 吃完就扔, 现在好了, 每隔一段距离都有垃圾桶了, 自然不会乱扔了(找得到垃圾桶又何必扔地上)

以前经常到处小便, 为啥因为公共厕所收费一块, 找个没人的地方哪里不是上, 现在到处都又免费的公共厕所

我相信吐谈也是同理, 如果一个城市里面很干净, 并且有对应的排泄物的处理方案自然没有人到处吐了.


当然高额的罚单也是可以做到的. 这样只会增加民怨,

@qrobot 想要改变随地吐谈的很容易

1. 禁止烟草销售
2. 禁止 生产 pm2.5 的工业设备运行
3. 对于喉咙不舒服的直接纳入医院进行治疗, 并且带薪治疗

执行以上标准, 你看看是否有人吐谈.

欧洲为啥到处小便, 你看看厕所收费多少. 同理为啥国内到处吐谈, 有没有一种可能不是因为别人想吐谈, 而是因为喉咙不舒服

我爱吐痰, 没有素质, 我不明白的是, 这些痰以及尿液还有大便, 这些不都是人体正常的代谢物吗? 我不吐地上我吐哪里? 咽下去吗? 文明指的是垃圾的集中管理, 例如冲水马桶, 请问在大街上有对应的吐谈的解决方案吗?

总不能因为所谓的文明, 强制不让你拉屎把?

特意上号给你回复, 如果是要抗震, 5w 肯定是不够的, c40 混泥土价格大概在 400~500 左右, 里面还要加钢纤维, 还要打地基, 我觉得 5w 肯定少了, 地基至少埋一米把, 还不如在建立一个地下室

@zhennann 两年之后你可以在回过头来看我说的这句话, 越简单的代码往往越可靠

@zhennann 你说了这么多我实在是看不到任何优点, 无非是把 Spring 这一套强行拿到 前端来, 这非常过度设计.

因为项目足够大, 一个 runtime 的开销非常恐怖, 你自己看看, 现在主流的都是想着怎么去 runtime , 反而你还在里面加 runtime 反其道而行之


webpack 之初就是为了 tree shaking 和 code splitting, 现在你把 tree shaking 的功能完全丢弃了.

其次你的想法很好, 站在项目工程角度上来考虑这个事情, 这些东西我觉得这完全是将简单的东西复杂化.

与以下的本质上有什么区别?

```
class Demo2 {
constructor(b2) {
this.b2 = b2
}
}
```

相对于 IoC, 这几点非常蛋疼


1. 会导致 tree shaking 完全失效
2. 多一个 runtime 开销
3. 增加调试的复杂度

@zhennann #9L

举个例子
```
import c1 from "xxx";


class Demo {
@Autowired
private: b2;
}

class Demo2 {

}
```

@qrobot 特定场景下 componentScan 很好用, 但是 OP 的 IoC 就有点本末倒置