对于可重用组件：

1. react在peerDependencies和 中放置依赖项devDependencies。
2. 千万不要把react依存性dependencies。

peerDependencies指定可重用组件支持/需要的 React 版本。使用 npm 2 时，这也会将 React 添加到要安装的module列表中，但 npm 3 不再是这种情况。

devDependencies确保npm install在开发组件时运行时或在 Travis 或类似设备上运行测试时安装 React 。

把react在dependencies将导致安装阵营的多个版本，如果有人使用您的成分，但有一个不同的版本在自己的阵营package.json-有发生react，不仅腌生成多个版本，而且会导致错误时，不同版本的尝试互动。

选定的答案绝对是这里规定的方法，但是我已经开始倾向于使用控制反转，而不是依赖 npm 对等依赖项来获取我的库依赖项，这对我很有帮助。

如果您构建函数式库，库会更容易。维护导出单个函数的库似乎更容易，该函数接收具有所有重依赖项的对象并导出包含每个库典型导出的对象。

库“注入”

库/索引.js

export default ({ React }) => {
  const InjectedComponent = props => (
    <p style={{color: props.color}}>This component has no React npm dependencies.</p>
  )

  /** other stuff */

  return { InjectedComponent }
}

消费应用

应用程序.js

import React from 'react'
import { render } from 'react-dom'

/** Import the default export factory from our library */
import createInjectedComponent from 'injected'

/** Call the factory, passing its dependencies (guaranteed to match what we're bundling) and get back our component */
const { InjectedComponent } = createInjectedComponent({ React })

render(<InjectedComponent color="blue" />, document.getElementById('root'))

如果您的组件仅适用于给定版本的 react 或其他一些依赖项，您可以围绕传入的 React 参数的版本编写一些断言。总的来说，以这种方式构建库应该不太容易出现新的构建问题版本的 React 已发布，更重要的是确保您不会导致您的库使用者捆绑多个版本的 React 和其他繁重的库。此模式适用于npm链接（我通常有 16 个以上的库npm同时从链接运行，并且在我不使用此模式时遇到问题）。

在你的主应用程序，我总是建议拆分出来react，react dom和任何reactlib组件，您使用到厂商束（的WebPack）并将其标记为外部在你的主束，这样你就不会在无意中捆绑两个版本。

您可以react在任一peerDependencies或dependencies。是该用的区别peerDependencies，react只安装一次使用你的包的包。如果你把它放在dependencies,react将被安装两次，一次是使用你的包的包，一次是你的包。

React 本身似乎peerDependencies出于某种原因而受到青睐。您显然不希望react在您的 Javascript 包中有两个单独的版本（如果您使用dependencies，默认情况下会发生这种情况），但是使用npm dedupe.

因此，有做不正确的方法，无论是peerDependencies和dependencies工作。使用dependencies更符合 node/NPM 的方式，但使用peerDependencies对不知道npm dedupe和为什么需要它的包的用户更友好。