首页/AI 提示词库/编程开发/依赖冲突解决

依赖冲突解决

⌨ 编程开发 适配:Claude / GPT / DeepSeek难度:进阶 4 个变量一键复制
使用说明

安装依赖报 ERESOLVE、peer dependency 冲突、版本互锁时的定位与解决:先判断谁和谁冲突,再选最小代价的方案。

npm install 报 ERESOLVE、升级一个包带崩一串包、CI 上装得上本地装不上。

提示词模板未填写变量以红色标出
我的依赖装不上了,帮我定位冲突并解决。

【环境】{{项目环境}}
【报错】{{报错信息}}
【相关依赖】{{涉及依赖}}
【锁文件情况】{{锁文件状态}}

请输出:
一、冲突链还原:把报错信息还原成「A 要求 B 满足 X,但实际装了 Y」的依赖链图(文字版),标出哪一条是真正的冲突边、哪些只是顺带提示。
二、方案对比:给 3 个方案按推荐排序——升级冲突方到兼容版本(给具体版本号)、用 overrides/resolutions 强制对齐(说明风险)、临时 legacy-peer-deps(说明为什么这是最后手段);每个方案给出完整命令。
三、版本兼容确认:升级前怎么确认目标版本真的兼容(去哪查 peer 范围、怎么用 npm view 查可装版本)。
四、锁文件处理:删 package-lock 重装的时机和代价、CI 与本地版本不一致的标准解法(.nvmrc/engines/统一包管理器)。
五、防复发:团队协作下依赖管理的 3 条约定(锁文件必须提交、升级走单独 PR、定期 npm outdated 巡检)。

要求:别上来就让我删 node_modules 碰运气;每个方案说清副作用,由我选。
填变量变量会自动替换进上方模板,可随时复制
已填 0 / 4
使用步骤
  1. 先还原冲突链,别盯着第一条报错。
  2. 优先升级到真正兼容的版本,overrides 是止血不是治疗。
  3. 锁文件永远提交,升级永远单独一个 PR。
ERESOLVE 看最后一段
npm 报错最后列出的 while resolving 段才是冲突现场,前面的树只是过程。
legacy-peer-deps 会埋雷
它只是跳过检查,运行时该崩还是崩,而且雷会一直藏在锁文件里。
常见问题
pnpm 为什么少这类问题?

pnpm 严格的依赖隔离让幽灵依赖显形,很多 npm 下潜伏的冲突在 pnpm 下装依赖时就会暴露。

overrides 会影响传递依赖吗?

会。overrides 改的是整棵依赖树里的版本,用前确认没有别的包真的依赖旧版本的特性。