17370845950

应根据项目实际痛点选择包管理器：npm 7+ 支持 workspaces 和自动安装 peerDependencies，但扁平化 node_modules 易致冲突；yarn berry 用 PnP 提升性能但兼容性差；pnpm 以硬链接节省磁盘和加速安装，但 symlink 结构可能影响路径遍历类工具。

选 npm 还是 yarn 还是 pnpm，不是看谁新，而是看你的项目有没有被 node_modules 占满磁盘、装包慢到想重装系统、或者 CI 构建总因依赖解析失败而挂掉。

npm 7+ 已经能解决大部分问题，但默认行为仍可能踩坑

npm 从 v7 开始默认启用 peerDependencies 自动安装，并引入 workspaces 支持单仓多包。但它仍按“扁平化”方式写 node_modules，容易引发版本冲突或隐藏的 require 错误。

• 运行 npm install 时若没加 --legacy-peer-deps，遇到不兼容的 peerDependencies 会直接报错中断
• npm ci 比 npm install 更可靠，它严格按 package-lock.json 安装，跳过 devDependencies 解析逻辑，适合 CI
• npm outdated 显示的是语义化版本范围内的可升级项，不代表实际能安全升级——得结合 npm view versions 看真实发布记录

yarn classic（v1）和 berry（v4+）根本不是同一个工具

yarn classic（即 yarn v1）用 yarn.lock 锁死解析结果，安装快、确定性强，但已停止维护；yarn berry（yarn v4）彻底重写，改用 .yarn/cache 和 PnP（Plug'n'Play），不再生成 node_modules。

• PnP 模式下，require() 不走文件系统，而是由 Yarn 注入的 .pnp.cjs 路由——这意味着部分依赖（如需要读取 node_modules 路径的 Babel 插件、Webpack loader）会直接报 Cannot find module
• 启用 PnP 后，必须用 yarn dlx 替代 npx，否则找不到二进制入口
• 若团队里有人用 VS Code，需额外装插件 Yarn PnP SDK，否则 TypeScript 类型提示会失效

pnpm 的硬链接机制对磁盘和 CI 最友好

pnpm 用符号链接 + 硬链接管理依赖，所有包只存一份物理文件，node_modules 里全是链接。这使得：

• 本地 pnpm install 比 npm 快 2–3 倍，node_modules 体积通常只有 npm 的 1/5
• pnpm store 默认在用户目录（如 ~/.pnpm-store），多项目共享缓存，CI 中只要缓存该路径就能跳过重复下载
• 但它的 symlink 结构会让某些老脚本崩：比如用 fs.readdirSync('node_modules') 遍历所有包名的工具，会漏掉被链接进来的子依赖
• 使用 pnpm recursive（或 pnpm -r）跑 workspace 命令时，当前工作目录仍是根目录，不是子包目录——这点和 lerna exec 行为不同，容易导致路径相关逻辑出错

pnpm add -r eslint --filter "./packages/*"

真正该关注的不是工具名，而是 lockfile 的内容和更新策略

无论用哪个工具，package-lock.json（npm/pnpm）或 yarn.lock（yarn）才是依赖一致性的唯一依据。很多人删了 lockfile 重装，以为“干净”，其实只是把问题延后了。

• 不要手动编辑 lockfile —— 它不是配置文件，是解析快照；修改应通过 pnpm update 或 npm update 触发
• 升级大版本（如从 React 17 → 18）前，先运行 pnpm list react 或 npm ls react，确认没有多个版本共存导致的 hook 冲突
• CI 中应固定 Node.js 版本（如 .nvmrc 或 .node-version），因为不同 Node 版本下 semver 解析结果可能微调，影响 ^ 范围匹配

最常被忽略的一点：所有工具都依赖你是否正确声明了 engines.node 和 peerDependencies。没写清楚，换谁都救不了你。