当尝试使用npm i命令安装npm包时,我得到了以下异常:
我尝试重新安装Node.js包,并使用以下方法将代理设置为关闭:
set HTTP_PROXY=
set HTTPS_PROXY=
问题仍然存在。我哪里做错了?
更新:
执行以下命令时:
npm install --legacy-peer-deps
系统显示如下错误:
当尝试使用npm i命令安装npm包时,我得到了以下异常:
我尝试重新安装Node.js包,并使用以下方法将代理设置为关闭:
set HTTP_PROXY=
set HTTPS_PROXY=
问题仍然存在。我哪里做错了?
更新:
执行以下命令时:
npm install --legacy-peer-deps
系统显示如下错误:
当前回答
以防万一,当我尝试npm升级当前的Angular 11时,我确实有类似的行为。或者基于Angular 12.x创建新的ng new abc。我只是忘了升级Angular CLI。所以这个npm install -g @angular/cli@latest解决了我在ng new abc期间的错误。
其他回答
问题似乎是gf-kautomata-pipeline-ui使用的是Angular 9,而@angular/http需要Angular 7。(@angular/http已经弃用并最终被移除,它的所有功能都被移到了@angular/common中。)
见:https://www.npmjs.com/package/@angular http
如果你运行的是Angular 9,那么
从包中删除@angular/http。json(在Angular 9中你不需要它) 确保你的package.json中有@angular/common。 运行npm i。
如果你运行的是Angular 7,那么打开你的包。检查并确保你所有的Angular包都不高于^7.0.0。你可能还需要删除gf-kautomata-pipeline-ui,或者联系gf-kautomata-pipeline-ui的作者,看看这个库是否与Angular 7兼容。
在这个案子上,我遇到了问题
无法解析依赖树
在一个Angular 13项目中,它使用了Azure DevOps中私有npm提要中的一些包。
为了访问这个存储库,我创建了一个.npmrc文件。正因为如此,npm install命令将搜索我的私有存储库中的所有包,而不再是npm feed中的包。无法解决依赖树错误是因为npm install命令找不到很多托管在npm提要而不是我的私有提要中的包。
我找到了一个关于如何确定包范围的惊人答案。
在此基础上,我做了一些修改:
在我的图书馆包里。Json,更新名称有一个作用域名@mylib “名称”:“@myLib /命令队列”, 构建并将此包发布到我的私人提要 在我的客户端应用程序(使用这个包的应用程序)中,更新.npmrc文件,只对这个范围内的包使用我的私有提要 @myLib:注册表= https://pkgs.dev.azure.com/..。 always-auth = true
现在,每当我运行npm install命令时,如果包的作用域是@myLib,它就会在我的私有提要中查找它,并在所有其他情况下使用npm提要(即@angular/…)
这是我的客户端应用程序包的一个例子。json文件:
"@angular/platform-browser-dynamic": "~13.3.0",
"@angular/router": "~13.3.0", <-- this comes from npm
"@myLib/jcg-command-queue": "^2.2.0", <-- This comes from my private feed
而且,有了这个改变,就不需要再在npm install命令中添加——legacy-peer-deps了。
在使用npm 7时,这种情况经常出现,因为对等依赖问题在版本7中被视为错误,而在版本6中通常只是警告。通常使用——legacy-peer-deps可以让它在npm 7中工作。
当这不起作用时,一个选择是降级到npm 6。降级Node.js是没有必要的(但也没有害处)。相关的依赖管理代码在npm中。降级Node.js通常是巧合,因为这样做通常也会降级npm。
另一个比降级npm破坏性更小的选择是使用npx来使用之前版本的npm的install命令:npx -p npm@6 npm install
当所有这些都失败时,通常值得尝试删除node_modules目录和包锁。Json,然后再次运行NPM install。这会重新生成node_modules和package-lock.json。
首先要了解问题。以下是我的错误:
npm ERR! ERESOLVE unable to resolve dependency tree
npm ERR!
npm ERR! While resolving: project-admin@11.0.0
npm ERR! Found: @angular/common@11.0.3
npm ERR! node_modules/@angular/common
npm ERR! @angular/common@"11.0.3" from the root project
npm ERR!
npm ERR! Could not resolve dependency:
npm ERR! peer @angular/common@"^9.1.0 || ^10.0.0" from @agm/core@3.0.0-beta.0
npm ERR! node_modules/@agm/core
npm ERR! @agm/core@"3.0.0-beta.0" from the root project
首先,你应该从下到上读这道题。这里@agm/core@3.0.0-beta.0需要通用的angular 9.1.0或10.0.0。最上面的消息说,角的公共发现实际上是11.0.3。
(如果你想更好地理解依赖关系,这里有一个非常简单的网站:如何npm3工作)
dependencies — these are the essential dependencies that you rely on and call in your project’s code
devDependencies — these are your development dependencies, for example, a prettier library for formatting code
peerDependencies — if you set a peer dependency in your package.json, you are telling the person who installs your package that they need that dependency with the specified version
optionalDependencies — these dependencies are optional and failing to install them will not break the installation process
bundledDependencies — it’s an array of packages that will come bundled with your package. This is useful when some 3rd party library is not on NPM, or you want to include some of your projects as modules
So what should be the solution then? The problem is about peer dependencies. The solution is to downgrade angular common or the solution is to use legacy dependencies logic for installing packages using --legacy-peer-deps. So --legacy-peer-deps does not try to install the peerDependencies automatically. Is this going to work for you? Probably, yes. But you should add specific instructions how to do that, or to make the use of --legacy-peer-deps automatic for future installation of the project packages with this code from one of the previous answers:
npm config set legacy-peer-deps true
In my case I installed the package and I tried to run ng serve, but because --legacy-peer-deps was used, there were dependency packages which were not installed. I had to install those manually (because I did not set the configuration from the code above). At the end installing about five packages manually, all with --legacy-peer-deps, I ended to a package that could not be installed and I did not try to continue, because my project was throwing warnings like crazy and there were a lot of packages for audit too. So my decision was not to use this package and to find an alternative.
我读到的其他解决方案:
downgrade Node.js to v14. This will downgrade npm. It might not be v14, but this was the version that was most widely downgraded to. Some people use Yarn to force package installation - personally I don't understand how this works, because I haven't used Yarn. downgrading Angular and the global Angular CLI version to version that will satisfy the requirement. In my case it is angular/common, and in the question it's angular/core, but both require downgrading the whole angular right (I am not sure about this here). the package you install might have a higher version that doesn't require downgrading Angular. You might try to use the https://updatepackagejson.com/ to upgrade your packages to the latest, but this is in case your project is quite new.
免责声明:这假设你使用的是npm v7
注意:如果你遵循兄弟注释的指示,它将创建一个用户范围的配置,不会在队友/机器/构建机器人之间保持同步。
基于项目的遗留对等依赖
您可能希望将遗留同行deps与您的项目绑定在一起,以便它在机器/开发人员之间扩散,而不会污染您的其他项目。
npm config set legacy-peer-deps true --location project
这将创建一个本地文件在.npmrc,你可以提交到你的存储库:
legacy-peer-deps=true
然后,你就可以跑了:
npm install
然后提交更新后的锁文件。
记住,位置,位置,位置:
per-project configuration (/path/to/my/project/.npmrc, see more): npm config set legacy-peer-deps true --location project per-user configuration (defaults to $HOME/.npmrc, see more) npm config set legacy-peer-deps true --location user or, as the default location is user anyway: npm config set legacy-peer-deps true global configuration (defalts to $PREFIX/etc/npmrc, see more) npm config set legacy-peer-deps true --location global or, as --global infers --location global npm config set legacy-peer-deps true --global
对于某些项目,修复依赖关系可能不是简单的
在我的案例中,我们有一个遗留版本的关键依赖项想要引入webpack v3(!) -但这是该项目的构建依赖项。
短期内最好的解决方案是使用遗留peer-deps作为保留。
如果你在紧要关头,你也可以考虑对依赖项进行分叉,并相应地调整它的对等依赖项——它们将你的项目指向分叉。