场景描述

在日常使用命令npm install / npm install XX下载依赖的操作中，我经常会遇到无法解析依赖树的问题（依赖冲突）

解决方法 --legacy-peer-deps

在NPM v7中，现在默认安装peerDependencies。

在很多情况下，这会导致版本冲突，从而中断安装过程。

--legacy-peer-deps标志是在v7中引入的，目的是绕过peerDependency自动安装；

它告诉 NPM 忽略项目中引入的各个modules之间的相同modules但不同版本的问题并继续安装，保证各个引入的依赖之间对自身所使用的不同版本modules共存。

原理说明

在package.json文件中，存在一个叫做peerDependencies（对等依赖关系）的对象，它包含了项目里需要的所有的包或则用户正在下载的版本号相同的所有的包（很绕，但意思就是对等依赖关系指定我们的包与某个特定版本的npm包兼容）；对等依赖关系最好的例子就是React，一个声明式的创建用户界面的JS库。

假设我们现在有一个HelloHWCloud工程，已经在其根目录下的package.json文件中的dependencies字段里声明了packageA作为依赖，而其下面有两个项目app_A和app_B，它们也依赖packageA。如果我们用dependencies而不是peerDepenedencies来声明，那么npm install安装完项目之后的依赖结构如下图所示：

从上图可以看出，packageA依赖包被安装了3次，造成了2次安装冗余。

而如果采用peerDepenedency来下载，就可以避免这个核心依赖库被重复下载的问题。还是上面那个场景，我们在项目app_A和app_B的package.json文件里的peerDependencies字段声明一下核心依赖库packageA，然后在根目录的package.json文件里的dependencies字段也声明一下packageA。接着再执行npm install，生成的依赖结构就会如下图所示

如上图所示，packageA就只会被安装一次。因此，npm 从版本v7开始，install就默认以peerDependencies的方式去下载了：

如果用户在根目录的package.json文件里显式依赖了核心库，那么各个子项目里的peerDepenedencies声明就可以忽略 如果用户没有显式依赖核心库，那么就按照子项目的peerDepenedencies中声明的版本将依赖安装到项目根目录里 而方式2就会导致一个问题：用户依赖的包版本与各个子项目依赖的包版本相互不兼容，那么就会报错（无法解析依赖树的问题（依赖冲突））让用户自行去修复，因而导致安装过程的中断。（因为是从npm v7引入的，因此npm v3-v6就不会发生这个错误）