扔掉 yarn,用回 npm

最后更新于

TL; DR

Yarn1 接近停止维护,而 Yarn2 扔掉了 node_modules (改变了运行代码的方式,需要整个生态一起努力才能勉强能用)。NPM 作为官方维护的主流包管理工具,一直在迭代新功能和修复 bug,从各种方面建议用回 npm。

常见命令 yarn → npm

yarn / yarn installnpm i yarn addnpm i yarn removenpm r yarn install --frozen-lockfilenpm ci yarn why xxxnpm why xxx yarn <script>npm run <script> 不存在npx <package>

常见功能

workspace

附赠

npm help <command> 可以查看一个 command 的帮助文档,在 Windows 等系统上他可以直接打开网页版的文档。

npm folders 可以阅读一份详尽的 npm 工作方式解释。

遗留问题

打平 node_modules 后遗症

例如某项目的一个依赖 A 的依赖里含有 C,那么就会存在 node_modules/C,假设在项目里写 require('C'),他也能正常运行。这其实仔细思考一下就会发现不合理:倘若项目存在两个依赖 A、B,他们一个依赖 C@1,一个依赖 C@2,此时如果写 require('C'),到底拿到的是什么版本的。

而且这并不直观:为什么一个库需要知道依赖的依赖(的依赖……)才能运行。

因此,最好的处理办法是每个库的依赖放在自己里面,别提到最上层。而这就带来了最开始的问题(也就是打平 node_modules 的目的):相同依赖不能合并、目录太深等等。所以说根本没有银弹,目前最好的解决办法是使用 symlink,或者在 Windows 上使用 Junction 来做到合并依赖(仍然会产生一定的链接文件占用,不过已经比占整个包小很多了),以及 Windows 用户去打开 [组策略 - 计算机配置 - 管理模板 -系统 - 文件系统 - 启用 Win32 长路径]。这一方案使 pnpm 诞生了,有兴趣可以去尝试一下。