Dependencies

首先dependencies是大家最常用的，比如项目依赖了vue，那么vue就是dependencies，这里的依赖是会被最终构建到部署环境的

// 将会保存到dependencies中
npm install vue --save
// 或者不写--save也可以，默认就会到dependencies中
npm install vue
// 再简单一些
npm i

DevDependencies

与之相对的是devDependencies，他是开发过程中的依赖，比如eslint，不可能线上压缩的代码包含eslint，所以显然他应该放入devDependencies。

npm install eslint --save-dev
// 或者
npm install eslint -D

其实如果是node.js开发，这一点就更明显，因为项目发布的时候并不会编译代码，构建的过程就是安装依赖的过程，而安装依赖会指明--production参数

npm install --production

使用这个参数意味着只安装dependencies，因为显然生产环境（dependencies）不需要开发环境（devDependencies）的依赖。

所以如果一不小心把某个生产环境的依赖写到devDependencies中，那么显然发布之后会引用不到这个依赖。

PeerDependencies

最后，peerDependencies相对难理解一些，但明确了使用的场景也同样很简单。

假设我们的项目使用了vuex作为状态管理器。不知道大家有没有注意，vuex并没有dependencies。虽然我们都知道vuex一定会依赖vue。可以直接点开这里看下vuex的依赖。

之所以vuex这样做，因为vuex知道你如果要使用他，就一定也会使用vue，所以他也就不会在dependencies中写入。事实上，这种情况是非常多的，尤其是对于插件而言，比如webpack，babel，eslint等等他们的插件都知道使用者一定会提供宿主自身（host）。

当然，插件仍旧是需要指明他所依赖宿主的版本号，而且他们往往对宿主环境依赖的版本号有更准确的要求。因为他们一般更可能会使用底层的api，而这些api可能在某一次minor或者patch的版本的升级中改变了。

为此，peerDependencies就派上用场了。

下面是vuex的package.json中的peerDependencies，显然他指明了自己希望的宿主vue版本号。

"repository": {
    "type": "git",
    "url": "git+https://github.com/vuejs/vuex.git"
  },
  "homepage": "https://github.com/vuejs/vuex#readme",
  "peerDependencies": {
    "vue": "^2.0.0"
  },

如果我安装了上述版本vuex之后，再安装vue3.0，就会报出一个警告：

yarn add vue@next
yarn add v1.22.5
[1/4] Resolving packages...
[2/4] Fetching packages...
[3/4] Linking dependencies...
warning " > vuex@3.6.0" has incorrect peer dependency "vue@^2.0.0".
[4/4] Building fresh packages...
success Saved lockfile.
success Saved 14 new dependencies.

看到这个提示，你就应该知道，你的vuex插件可能与当前的vue不兼容。

参考

Peer Dependencies