一直在使用NPM版本的6.14.7
,并决定继续使用NPM版本的7.20.1
为我的反应-本机项目。当我尝试npm install
时,我的大多数库都会因为Could not resolve dependency:
的错误而中断
示例
// example 1
npm ERR! Could not resolve dependency:
npm ERR! peer react@"^16.8" from @react-native-community/async-storage@1.12.1
// example 2
npm ERR! Could not resolve dependency:
npm ERR! peer react@"^16.0" from @react-native-community/picker@1.8.1
// More Example(s)
..
...
.....
我知道中断对等依赖项声明的更改是由NPM团队制造的。这里需要一些指导,我怎样才能无缝地升级我的npm版本?
自动安装对等依赖关系是npm 7中引入的一个令人兴奋的新特性。在npm的早期版本(4-6)中,对等依赖冲突提供了一个警告,即版本不兼容,但仍然会安装依赖关系而不会出现错误。如果存在无法自动解决的上游依赖冲突,npm 7将阻止安装。
当然,--我知道以下选项--。如果我要执行npm install --legacy-peer-deps
,难道这与我使用NPM 6不一样吗?因为它只通过传递自动安装对等依赖项。
您可以选择使用“强制”来绕过冲突,或者使用“遗留对等-deps”命令完全忽略对等依赖(此行为类似于版本4-6)。
决定
只是为了分享我的想法,希望能帮助别人。
经过更多的阅读(link1,link2)以及@Dan Macák
和@M. Erim Tuzcuoglu
共享的评论之后,我决定暂时继续使用NPM6。
主要而言,我认为这些努力和风险远远高于升级到NPM7的回报?无论如何,我不需要NPM7中提供的新特性
我也尝试过使用@M. Erim Tuzcuoglu
建议的NVM,然后使用不同的NVM + NPM切换,最终从xcode中命中一个问题(命令PhaseScriptExecution失败了一个非零退出代码)。我认为原因是nvm is not compatible with the "PREFIX"
许多人都面临着这个问题。,并想出了一些解决方案,但我决定不再做进一步的工作,因为这似乎使项目更加复杂(其他团队成员需要做同样的NVM设置)
发布于 2021-07-25 16:11:38
恐怕您的项目要切换到npm 7并不是一种简单的方法,而是通过自动安装来使我们的生活变得更容易(考虑到您的问题有点讽刺),这涉及到处理无效的依赖树;虽然这是一件好事情,可以防止难以找到的bug(例如。由于插件期望在项目中使用不同版本的React,并因此失败),如果忽略安装警告(有时谁不会错过它们?),切换可能会很痛苦。
因此,尽管NPM应该处理许多依赖关系差异本身(来自https://github.blog/2021-02-02-npm-7-is-now-generally-available/):
由于生态系统中的许多包都依赖于松散的对等依赖解决方案,npm 7将打印警告并解决包树中存在的大多数对等冲突,因为您无论如何都无法修复这些冲突。
当手动操作无法解决依赖关系时,仍然需要采取手动操作。如果您还想使用npm 7,这里有两个选项:
npm ls
没有成功运行,您应该考虑一下这个选项。不幸的是,对于某些具有非常狭窄的peerDependencies
需求的包来说,这可能是很困难的,而库作者在指定它时应该非常小心地使用。--legacy-peer-deps
来忽略npm i
期间的所有peerDependencies。FWIW,如果你没有时间做前者,也不想因为后者而改变你的工作流程,并且不需要npm 7的真正改变,那么暂时保持在版本6上是很好的。
发布于 2021-09-07 13:05:11
我也有同样的问题,当我进一步调查它时,我发现一些包已经被移动了,这就是为什么解决依赖关系失败的原因,例如
@react-native-community/async-storage >> @react-native-async-storage/async-storage
我知道这个问题比一个问题需要一个解决方案更有哲理性,但我同意npm解决依赖关系黑洞的观点,让我们继续前进
发布于 2021-07-25 14:46:29
您可以使用节点版本管理器
https://stackoverflow.com/questions/68519568
复制相似问题