I've tried updating npm after I did some WARNings, so I went
npm audit fix
received way more WARNs. Now when i tried installing all dependencies with
npm i
I got tons of WARN (see below). I honestly haven't got a clue what any of these mean, but did not have any before the npm fix.
Looks like you're using deprecated packages.
Try running
npm outdated
it will show you the current version, desired version, and latest version for each of your package. That won't actually do anything to your project, but it's a good first indication.
If you run
npm update
it will update each package according to what your package.json says.
For instance if you see this in your package.json
"my-package": "~1.25.0"
it means that npm update will update to (or that npm install will install) version 1.25.0 or the latest patch version such as 1.25.4.
If you see
"my-package": "^1.25.0"
it means that npm update will update to (or that npm install will install) version 1.25.0 or the latest minor or patch version such as 1.26.2.
However, npm update will not update your packages to new major versions. That means that "my-package" will not be update to 2.0.0 for instance.
I think using old version of packages can cause those kinds of warnings.
In that case, just reinstall the package to the latest version
npm uninstall my-package
npm i my-package
⚠️ But be careful as updating a package to a new major version could break your code!
My advice is to do it step by step and make sure you can always roll back in case there's a problem you don't understand!
Related
Just ran into this error:
npm ERR! code ERESOLVE
npm ERR! ERESOLVE unable to resolve dependency tree
npm ERR!
npm ERR! While resolving: nexttwin#0.1.0
npm ERR! Found: react#17.0.1
npm ERR! node_modules/react
npm ERR! react#"17.0.1" from the root project
npm ERR!
npm ERR! Could not resolve dependency:
npm ERR! peer react#"^16.8.0" from react-hook-mousetrap#2.0.4
npm ERR! node_modules/react-hook-mousetrap
npm ERR! react-hook-mousetrap#"*" from the root project
npm ERR!
The module I am trying to install seems to have a different peer dependency from what I have installed. It seems like npm changed its behaviour in this regard and now lets the install fail.
What can I do now to fix this? I don't want to downgrade my React version for this.
I know there is a flag called --legacy-peer-deps but I am not sure what exactly this does and whether it's recommended to use it / what the potential disadvantages are? I assume there is a reason npm did let the install fail.
It's just strange because I was using yarn up until very recently and everything was fine.
TL;DR:
You may be arriving upon this answer if you're upgrading from NPM v6 / Node v12.
NPM v7+ installs peerDependencies by default; this is not the case with previous versions of NPM.
NPM modules must name specific versions of their peerDependencies
If you already have a peerDependency installed, but not with a version named by the module, then NPM v7+ will throw an error
Adding --legacy-peer-deps ignores this new requirement, at the risk of introducing breaking changes
--legacy-peer-deps restores peerDependency installation behavior from NPM v4 thru v6
One way of thinking of this flag is that it isn't doing something new; rather it's telling NPM not to do something new, since NPM v7 now installs peerDependencies by default.
In many cases, this is leading to version conflicts, which will break the installation process.
The --legacy-peer-deps flag was introduced with v7 as a way to bypass peerDependency auto-installation; it tells NPM to ignore peer deps and proceed with the installation anyway. This is how things used to be with NPM v4 thru v6.
If you're unclear about the difference between regular deps and peer deps, here is a bit of context:
Dependencies vs peerDependencies
Dependencies: Libraries or modules that an NPM module needs in order to work in production. (Example: I recently built a pie chart mocking library that uses Chance.js to calculate random numbers within a specified range; Chance is therefore a dependency of my module.)
peerDependencies: A peer dependency is a specific version or set of versions of a third-party software library that a module is designed to work with. They're similar in concept to the relationship between a browser extension and a browser. (Example: react-redux has two quite logical peerDependencies: react and redux.)
This issue is being driven, in part, by React v17+
Due to the large number of modules that haven't specifically added React v17 (or more recently, React 18) as a peerDependency, it's now commonplace to encounter the unable to resolve dependency tree error when running npm installs within a v17 React application.
This error will fire whenever a module (or any of its own dependencies) lists a previous major version of React as a peerDependency without specifically including React v17 as well.
(Note: Similar behavior will occur with the major-version update of any other framework or library.)
How to check peerDependencies for any given module
NPM itself doesn't list peer deps on the pages of a given module. However, there is a simple workaround to check for peer deps, either before or after install. Simply run:
npm info name-of-module peerDependencies
This command will return the name of each peerDependency along with all compatible version(s).
Here's how I solved this problem:
First, what's happening: react-hook-mousetrap is looking for react#16.8.0, but it is not finding it. Instead it is finding #react17.0.1, which is a newer version. For some reason mousetrap doesn't like this newer version, and you are being notified (it is not a big deal, but they decided it was worth stopping your build).
One solution: forcibly install the specific version of react that mousetrap wants:
yarn add react#16.8.0
What this does is roll back your react version to a slightly older one that is compatible with mousetrap. You won't notice any difference, and in future iterations, hopefully mousetrap is updated, so this goes away.
Another solution: make a sweeping decision to not install any older version dependencies:
npm add xxxx --legacy-peer-deps
What this does is ignore old dependencies for this package. It is more comprehensive, and makes a lot of the decisions for you.
I resolved (with yarn) adding the following to package.json
"resolutions": {
"**/react": "17.0.2",
"**/react-dom": "17.0.2"
},
If you don't want to block installing older dependencies, you can make npm neglect those warnings by forcing the script you're running. --force
--leagcy-peer-deps jumps the installation of all the peer dependencies and gives warnings about the peer deps to notice developers install them manually. When encountering the peer deps conflicts, other than --legacy-peer-deps, another choice is use --force.
The official doc of handling peer deps conflicts is this
p.s.
Correct the top answer: --leagcy-peer-deps restores peerDependency installation behavior from NPM v3 thru v6, rather than v4 thru v6.
One other way is to downgrade your npm version to version 6
legacy-peer-deps:
Default: false
Type: Boolean
Causes npm to completely ignore peerDependencies when building a package tree, as in npm versions 3 through 6.
If a package cannot be installed because of overly strict peerDependencies that collide, it provides a way to move forward resolving the situation.
This differs from --omit=peer, in that --omit=peer will avoid unpacking peerDependencies on disk, but will still design a tree such that peerDependencies could be unpacked in a correct place.
Use of legacy-peer-deps is not recommended, as it will not enforce the peerDependencies contract that meta-dependencies may rely on.
If you want to continue using legacy-peer-deps without needing to add the flag to every command, you can configure it in your .npmrc (either at the project level or globally on your machine):
echo "legacy-peer-deps=true" >> .npmrc
npmrc:
npm gets its config settings from the command line, environment variables, and npmrc files.
The npm config command can be used to update and edit the contents of the user and global npmrc files.
I have a private npm library. We are using semvar approach and version our projects via:
npm version {patch, minor, major}
So that users can install it via:
npm install mylib#1.5
npm install mylib#2.3.7
...
Now, I have run into the use-case that I want to give developers early access to an unstable version of my library.
It seems that dist-tag should fit my needs. Therefore, I want to release a beta dist-tag so that developers can install that unstable state via
npm install mylib#beta
So within my unstable branch, I tried publishing the beta branch but got the error:
npm publish --tag beta
npm ERR! code EPUBLISHCONFLICT
npm ERR! publish fail Cannot publish over existing version.
npm ERR! publish fail Update the 'version' field in package.json and try again.
npm ERR! publish fail
npm ERR! publish fail To automatically increment version numbers, see:
npm ERR! publish fail npm help version
This confuses me.
I want to avoid bumping the semvar version to begin with. I was expecting this to only publish its current state as a npm dist-tag to the repository. (And that I could push whatever I want to that tag name as it is a meta-pointer.)
Only once my branch becomes stable and is merged into the main branch, I intended the version bump (minor, in this case).
So just for trying it out, I bumped the version before and then published the beta tag, yet this also publishes the newly created minor version, making it available ahead of release time which is not want I want as now people could jump into an unstable future version of mine.
I don't understand how dist-tags and package's versions are supposed to be used in conjunction with the semvar versions and why I would need to bump the version for a tag as well.
I can not run the Angular 2 project.
What I tried:
- running the project by using npm install and npm start | does not work
- I cloned quickstart from the github and replaced with my src folder and I still get the "can not find module in #angular/core"
Here is the full console output: https://www.dropbox.com/s/5plmqrjd6ge0lta/error.txt?dl=0
Many people will come here. I have had the same problem. Do not panic. You are probaly following the tutorial of tutorialspoint.
Just install the core again using NPM
npm install #angular/core
There was/is a bug in certain versions of npm that causes installed modules to disappear when using npm install someModule ... or npm install someModule --save-dev
This was apparently an issue if the module being installed was from a GitHub repo and lacked a specific commit hash to reference for the installation. Although the issue was marked "closed" and the repo archived several months ago at v5.6.0, I ran into the problem today w/the latest npm 6.4.0
In my case, doing npm install rxjs completely removed the #angular/core module, along with my #ionic-native plugins, and anything else I'd installed individually (and then it failed to actually/properly install rxjs anyway!!)
Tip: copy your existing npm modules folder as a backup before starting updates or removing it entirely & trying to npm install.
You can manually install to your project via npm install #angular/core, but depending on the npm version (or the angle of the moon at that precise moment, who knows) be aware that you might wind up with other missing dependencies.
Also try npm install #angular/core && npm install ... Apparently the additional npm install helps replace the randomly deleted/missing modules in some cases.
Using private npm, common commands seem not to work:
npm install without a specific #version :: issue
npm outdated :: issue
npm update :: issue
npm view <private-package-name> versions :: (haven't found issue yet)
also note that npm v, npm show, and npm info are aliases that likewise don't work
Frequently, I will not know the latest version of a private module my team maintains. I would fall back on one of the commands listed above, but they seem inoperative. How can I install a package without knowing the latest version?
If I understand your question, installing latest package would be:
npm install <package_name>#latest --save
According to the documentation, running npm install package-name is supposed to install the latest version the registry knows about. This may be different for private npm instances, but there doesn't appear to be so as they reference private repos in the documentation as well.
npm install [<#scope>/]<name>#<tag>:
Install the version of the package that is referenced by the specified
tag. If the tag does not exist in the registry data for that package,
then this will fail.
Example:
npm install sax#latest
npm install #myorg/mypackage#latest
From: https://docs.npmjs.com/cli/install on Nov 23, 2016
The solution I ultimately arrived at was to use the #* syntax when running the install:
npm install --save my-off_the_hook-module#*
This seems kind of sloppy to me but it does save the latest version of the module in a manner that is, so far as I can tell, equivalent to the more familiar (and my opinion more explicit) #latest syntax.
I'm on Ubuntu 14.04 trying to install this package: https://www.npmjs.com/package/stanford-corenlp
However, whenever I try to do so, it tries to install node-java 0.5.5 as a dependency which fails (gives me node-gyp errors).
I looked this issue up, and it's fixed by using a newer version of node-java. 0.6.1 seems to work fine, but I don't know how to update the dependency to install the stanford-corenlp package.
add
"node-java": "^0.6.1"
in 'dependencies' of your package.json file. Then run npm install. This will install the right version of node-java.
Then try to install standford-corenlp. If they didn't hardcode the node-java version in their package.json, you should be alright