为何同时在peerDependencies与devDependencies中配置React及React-DOM？

这个问题在Monorepo开发React组件库/工具包时特别常见，结合你给出的Monorepo场景（已有Next.js项目安装了React），拆解如下：

一、同时配置的原因 #

1. peerDependencies：约束宿主环境的依赖规则 #

• 核心作用是声明你的包（这里的core-lib）必须依赖宿主项目提供的特定版本React/ReactDOM。React的Hooks机制要求全局只能有一个React实例，重复安装多个实例会直接导致hooks报错；同时也能避免打包时重复塞入React代码，减少产物体积。
• 在你的Monorepo里，nextjs-app已经装了React，core-lib通过peer声明后，会直接复用宿主的React包，不会额外安装冗余依赖。
• 版本用^18.2.0是允许宿主使用18.2.x的兼容小版本，兼顾版本一致性和灵活性。

2. devDependencies：满足本地开发/构建的刚需 #

peerDependencies只是“要求宿主有”，但它不会自动安装这些依赖——而开发core-lib本身时，本地环境必须要有React才能正常工作：

• 编辑器（比如VS Code）需要React模块/类型定义来提供代码提示、语法检查，不然写组件时会报“找不到模块'react'”的红色报错；
• 构建工具（tsc、rollup）、测试工具（jest）运行时，必须能找到React模块才能编译、执行你的组件代码；
• dev里用固定版本18.2.0，是为了开发时保持版本统一，避免因版本差异导致的开发环境问题。

二、仅配置peerDependencies能满足开发需求吗？ #

绝对不行。原因很直接：

• npm/yarn/pnpm默认不会自动安装peerDependencies里的包（除非手动加--install-peers参数，但这不是默认行为）；
• 没有本地的React依赖，你的代码在编辑器里会持续报错，构建、测试流程也会直接失败；
• 哪怕Monorepo里其他项目有React，也不代表core-lib能自动关联到——不同包管理器的workspace hoisting规则有差异，明确声明dev依赖更可靠，避免依赖查找的不确定性。

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