主项目A中第三方依赖C为库B的peer dependency时，能否移除A中的C？

先明确背景：

• 宿主应用A依赖库B@2.0.0，同时直接依赖第三方库C@1.0.0
• 库B将C声明为peer dependency，且两者使用的C版本一致（均为1.0.0）

下面分两部分解答你的疑问：

能不能移除A中的C？ #

取决于两个核心条件：

• 如果A没有直接调用C的任何API，只是B需要C作为peer依赖，理论上可以移除A的dependencies里的C声明。
• 如果A自身代码里直接用到了C，那绝对不能移除，否则会出现「找不到模块」的运行时错误。

移除后可能存在的问题 #

即使A没有直接用C，移除声明也可能带来这些风险：

• 包管理器兼容性问题
  • npm v6及更早版本不会自动安装peer依赖，移除C后，安装依赖时会抛出peer依赖缺失的警告，且node_modules里不会有C，直接运行A会报错（B找不到依赖的C）。
  • npm v7+或yarn虽会自动安装peer依赖，但如果B的peerDependencies里写的是版本范围（比如^1.0.0），可能会安装1.x.x的最新版，而非你原本需要的精确1.0.0，进而引发版本兼容问题。
• 未来维护隐患
  • 如果后续A的代码新增了直接使用C的逻辑，而此时A没有声明依赖C，会突然出现运行时错误，排查成本较高。
• 团队协作成本上升
  • 团队成员若使用不同版本的包管理器，会出现环境不一致的情况：用npm v6的开发者需要手动安装C才能运行项目，增加协作门槛。
• 构建/部署失败风险
  • 部分CI/CD环境可能依赖package.json的声明来安装依赖，或者使用较旧的包管理器，移除C后会导致构建流程因缺失依赖而失败。

建议 #

如果A确实没有直接使用C，且团队统一使用npm v7+/yarn，同时B的peerDependencies严格锁定了C@1.0.0，你可以尝试移除。但更稳妥的做法是保留A对C的依赖声明：

• 确保无论包管理器版本如何，项目都能稳定获取到正确版本的C
• 明确项目的依赖关系，提升代码可维护性
• 避免后续新增C相关代码时出现意外错误

内容的提问来源于stack exchange，提问作者EchtFettigerKeks