Error: Does Not Satisfy Its Siblings' peerDependencies Requirements
解决方案
通过npm update更新那个报错的包。注意：更新报错的包，而不是正在安装的包。
探索
问题解决之后，我深究了一下原因，发现peerDependencies这个字段的意义。
1. npm如何解决包的依赖？
先考虑一般的情况：module A 依赖于 moduleB 1.0版本，module C依赖于moduleB 2.0版本，那么这个没有问题，因为moduleB是属于dependence字段或者devdependence字段，moduleB会被安装在module A和module C的内部，各自使用不同的版本也不会冲突。
但是，我们考虑插件机制，比如gulp。gulp是一个构建工具，有许多围绕gulp开发的插件，开发者在开发此类插件的时候一般是不会把gulp本身包含在正在开发的包里面的。我们使用者之所以能够正常使用这些插件包，那是因为我们提前安装好了gulp包。也就是说，gulp插件包依赖于包以外的gulp包，这个时候，你就可以把gulp写在gulp插件包的peerdependence字段，peerdependence里面的包安装路径与当前包同级。当然，你也可以不这么做，直接显式地安装gulp也是可以的。
2. 那么问题来了
考虑在全局安装的条件下，module A的peerdependence是 module B 1.0版本，你以前已经安装过module A了，所以会默认安装module B 1.0版本（跟module A）同级。现在，你要安装module C，里面的peerdependence是module B 2.0版本，这是可能的，比如不同插件开发的时候依赖的版本很可能不一样。那么，就会造成版本冲突，因为module2.0跟原先已经安装的module1.0版本冲突了，而且是同一个位置，npm就会报上面的错误。
起因
我在装npm的时候不时会碰到这个错误：
解决方案
通过npm update更新那个报错的包。注意：更新报错的包，而不是正在安装的包。
探索
问题解决之后，我深究了一下原因，发现peerDependencies这个字段的意义。
1. npm如何解决包的依赖？
先考虑一般的情况：module A 依赖于 moduleB 1.0版本，module C依赖于moduleB 2.0版本，那么这个没有问题，因为moduleB是属于dependence字段或者devdependence字段，moduleB会被安装在module A和module C的内部，各自使用不同的版本也不会冲突。 但是，我们考虑插件机制，比如gulp。gulp是一个构建工具，有许多围绕gulp开发的插件，开发者在开发此类插件的时候一般是不会把gulp本身包含在正在开发的包里面的。我们使用者之所以能够正常使用这些插件包，那是因为我们提前安装好了gulp包。也就是说，gulp插件包依赖于包以外的gulp包，这个时候，你就可以把gulp写在gulp插件包的peerdependence字段，peerdependence里面的包安装路径与当前包同级。当然，你也可以不这么做，直接显式地安装gulp也是可以的。
2. 那么问题来了
考虑在全局安装的条件下，module A的peerdependence是 module B 1.0版本，你以前已经安装过module A了，所以会默认安装module B 1.0版本（跟module A）同级。现在，你要安装module C，里面的peerdependence是module B 2.0版本，这是可能的，比如不同插件开发的时候依赖的版本很可能不一样。那么，就会造成版本冲突，因为module2.0跟原先已经安装的module1.0版本冲突了，而且是同一个位置，npm就会报上面的错误。
3. 为什么解决办法是更新或者重装？
为什么更新或者重装module B就可以解决问题。我们设想，module A插件先写，那时候的module B版本还很低，所以module A在peerdependence里面写上，需要不低于1.0版本的module B。过了一段时间，module B升级到2.0了，module C开发的时候是基于2.0的，所以它在自己的peerdependence里面写上，需要不低于2.0版本的module B。但是，此时你电脑里面的module B还是1.0版本。所以只需要更新module B到最新版本2.0，那么就可以同时满足module A和module C的需要了。
更新：
参考资料：