npm 7及之后版本为何仍选用peer dependencies而非常规依赖？

场景说明 #

假设你正在开发cool-app，项目依赖配置如下：

"dependencies": {
  "react": "^16.0.0",
  "cool-package": "^1.0.0"
}

但cool-package的peer依赖要求是React 18：

"peerDependencies": {
  "react": "^18.0.0"
}

不同npm版本下的安装行为 #

• npm 4/5/6版本：执行npm install时，会收到peer依赖未满足的警告，不会自动安装React 18——因为peer依赖的设计逻辑是要求宿主项目提供符合版本的依赖。
• 若cool-package将React设为常规依赖（版本要求^18.0.0）：执行npm install时，npm会下载React 18，与项目已有的React 16共存，因为常规依赖是包自身的独立依赖，和宿主项目的依赖互不干扰。
• npm 7及以上版本：peer依赖未满足时，会自动安装缺失的版本，行为和常规依赖类似，因此cool-app会同时存在React 16和18两个版本。

核心差异 #

peer依赖和常规依赖的本质定位完全不同：

• 常规依赖：是包运行必须的独立依赖，属于包自身的依赖树。当宿主项目的依赖版本与包的要求不兼容时，npm会自动安装新的版本，保证包能正常运行，不会影响宿主的依赖。
• Peer依赖：是包声明的、需要宿主项目提供的依赖，设计初衷是复用宿主环境的依赖实例，避免重复安装，同时保证兼容性。即便npm7+会自动安装缺失的peer依赖，这也只是兜底的开发体验优化，并没有改变它“依赖宿主提供”的核心定位。

实际应用中的重要性 #

1. 减少体积冗余：比如React组件库使用peer依赖，多个同类型组件库可以共享宿主项目的React实例，不会重复安装多个React版本，有效减少项目打包体积。
2. 保证实例一致性：对于React、Vue这类框架，多实例共存会导致状态无法共享、组件渲染异常（比如React Context在多实例下无法正常传递）。peer依赖强制复用宿主的依赖实例，从根源避免这类问题。
3. 明确版本管理责任：peer依赖将依赖版本的管控权交给宿主项目，开发者可以统一升级依赖版本，所有依赖该peer的包都会自动适配；而常规依赖的版本由包自身维护，宿主无需干预，但也无法统一管控。
4. 提前规避兼容风险：peer依赖会明确告知开发者“该包仅支持某个版本范围的依赖”，即便npm7+会自动安装兜底版本，开发者仍能通过依赖声明提前发现潜在的兼容性问题，避免上线后出现异常。

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