正如npm文档中所解释的,在npm v7迁移之后,现在默认安装了PeerDependencies。
如果不能正确解析树,尝试安装另一个要求冲突的插件可能会导致错误。
什么时候一个插件被认为是一个冲突的需求?他们说的树不能被正确解析是什么意思?
因此,我创建了不同的用例,以便更好地理解,请告诉我,如果我是正确的。
用例1
我的项目的Package.json
{
//...
"dependencies": {
"a": "1.0.0"
}
}
包. json的
{
//...
"peerDependencies": {
"b": "^2.0.0"
}
}
结果如下:
node_modules
|--- a (v 1.0.0)
|--- b (v 2.0.0)
用例2
我的项目的Package.json
{
//...
"dependencies": {
"a": "1.0.0",
"b": "2.5.0"
}
}
包. json的
{
//...
"peerDependencies": {
"b": "^2.0.0"
}
}
结果如下:
node_modules
|--- a (v 1.0.0)
|--- b (v 2.5.0)
用例3
我的项目的Package.json
{
//...
"dependencies": {
"a": "1.0.0",
"b": "3.2.0"
}
}
包. json的
{
//...
"peerDependencies": {
"b": "^2.0.0"
}
}
结果如下:
node_modules
|--- a (v 1.0.0)
|--- node_modules
|--- b (v 2.0.0)
|--- b (v 3.2.0)
最后一个用例工作吗?在哪个用例中,它不能解析树?
1条答案
按热度按时间nvbavucw1#
如果npm不能解析依赖树,那么您根本就不会安装所有内容(nothing in
node_modules
,nopackage-lock.json
).默认情况下会抛出一个错误,因为在安装之前,npm会解析整个依赖树.您可能希望强制和隐藏与--legacy-peer-deps
的冲突,以不考虑peerDependencies
和其他版本不匹配,但是,我不建议你这么做。情况1:无冲突。主包在
package.json
中没有直接的b
。b@2.0.0
包被提升到顶层(npm使用平面node_modules方法)并安装,因为它对于您的子依赖项是必需的。案例2:没有冲突。您的主包具有
b@2.5.0
直接依赖关系,这完全满足A的子包要求,即具有b@2.*.*
作为peerDeps。因此,b@2.5.0
安装时没有任何问题。情况3:peer conflict. npm将抛出错误
ERESOLVE unable to resolve dependency tree
,因为它不能自己解决。node_modules和锁文件都不会执行任何操作。a
要求包b
的版本为2.*.*
,但您的主包具有更高的版本b@3.2.0
。差异在于主版本。因此,您正在尝试集成不兼容的模块(包)。a
升级到peerDependencies
包含"b": "^3.0.0"
而不是"b": "^2.0.0"
的较新版本,或者将主包的b
从3.2.0
降级为任何2.*.*
。b
,请将b
从peerDependencies移动到a
的package.json中的依赖项。npm将以嵌套的方式在node_modules中保存它自己的b
版本。npm不会提升它,因为树中已经有另一个更高的版本。因此,b@3.2.0
将存储在顶层,并且b@2.0.0
将按照您在上一个代码片段中显示的那样安装。