哎，前端的包管理有那么一点割裂

[king888]

• npm
• yarn v1
• yarn v2
• pnpm

不同的项目对不同的包管理选择的情况是不同：

• 可能用户常用的是 pnpm ，但是 a 项目对 pnpm 支持不友好，又或者 b 项目用的 pnpm ，但是用户常用的是 yarn
• 又或者老项目用的 yarn v1 ，听说 yarn v2 新特性不错想试试，结果我是十有八九都需要手动调整费事费力，直接放弃
• 新项目当然想用新的包管理，新的特性
• 综上所述，电脑里不把这些七龙珠集齐都不好意思了
• 如果对电脑有点洁癖什么，需要自定义全局缓存位置什么的，各个包管理文档配置什么的又要找遍
• 没有统一的包管理，这么割裂的情况还是比较考验耐心的

[cheneyzhang]

只要运维愿意配合，前端可以做到同一个公司下统一包管理工具的

[GreatAuk]

💡 Use the right package manager: https://github.com/antfu/ni

[theprimone]

@GreatAuk 哈哈哈，我在公司安利好久终于不少人用上了

[theprimone]

另外 yarn v2 很久以前尝试升级过，各种折腾结果项目都起不来，索性没碰过了。

[renmu]

项目下是哪个 lock 就跑哪个，能跑起来就行

[wangtian2020]

一直用 npm ，配合 nrm 设置 proxy ，没啥体验问题

[bjfane]

@GreatAuk ni 只是解决命令的问题，对我来说各种工具命令没什么 仓库有好几个在我的 ssd 上 我就想吐。

顺便说一下 pnpm 在 6 ～ 7 版本改过默认路径，有可能你的电脑上 pnpm store 有两个，
macos 的话 /Users/xxxx/.pnpm-store 老路径
/Users/xxx/Library/pnpm/store/v3 新路径

[gam2046]

VS Code Remote in Container 可以变相的解决这个问题。毕竟都相互隔离开了。

[hhjswf]

前端娱乐圈

[cmdOptionKana]

这算割裂？好歹还是围绕 js/ts ，一共也就这么几个东西。后端呢？后端光是语言就几十种，主流的也有近 10 种，每种语言又可能有多种包管理。

如果因此就说前端是娱乐圈，那后端是啥？

[jqtmviyu]

现在一般不用 yarn 了, npm 后来不也支持扁平树 /离线安装 /lockfile 了吗?
有什么特性是 yarn 显著比 npm 领先的吗?
能用 pnpm 就 pnpm, 不能就 npm

[dcsuibian]

前端一般是：这个库已经烂了，别维护了，另开个新的吧

[9ki]

确定蛋疼, 但是不可否认的是每个技术都有其解决的痛点, 其实普通开发者会 `npm install` 和 `yarn` 完全足够了, 其他的技术当你需要他的时候再去使用也不迟.

不过就像楼主说的, 每个包管理器缓存很难管理, 特别是我这种就 256G 储存空间, 每月都要手动清理一次.

[xqk111]

都用过，还在回到 npm ，兼容性好点，

[xqk111]

@9ki pnpm 设计就是解决这个问题，我现在电脑里也是一大堆 node_modules ，npm 设计之初可能没考虑到这个事情吧

[vivipure]

用 pnpm 把，比较省空间。

[mmc]

我觉得好的包管理器应该是安装时可以很顺畅，可以直接拉编译好的二进制文件，而不是用我的电脑在跑一次编译。每次看到旧项目，想要试一下，npm install 突然来个要编译的包，要装各种库，最后编译还崩溃了，说的就是你：node-sass!

[king888]

@cmdOptionKana
就拿前端的包管理跟 golang 的对比吧，别人说娱乐圈，是有道理的

[wu67]

npm 大法好. 包管理各种层出不穷, 什么 cnpm yarn pnpm, 但是你看 npm 退出舞台了吗?

[yinzhili]

@cmdOptionKana 前端写好项目，过个两年后再去编译时，出错的概率非常高，后端显然没有这么恶心的问题