Recently I've been a little bit annoyed because after building my project I get a message like this nearly EVERY DAY:
╭────────────────────────────────────────────────────────────────╮
│ │
│ New patch version of npm available! 6.14.6 -> 6.14.8 │
│ Changelog: https://github.com/npm/cli/releases/tag/v6.14.8 │
│ Run npm install -g npm to update! │
│ │
╰────────────────────────────────────────────────────────────────╯
so I run npm install -g npm and a few days later or so it's there again with a newer patch (at least I assume so, since I executed that script successfully and don't know of anything that reverts it).
I'm very happy that people are improving it, but is there an easy way for this to update itself?
Because I'd rather manually downgrade it than having to manually upgrade it every time.
Your message above indicates that you are using npm version 6.x. That release line does not get a new release every day or even every week. In fact, the version in that message (6.14.8) was released 2 months ago. Judging from the 6.x release history, npm 6.x was getting updated about once a month. Now that 7.x is out, it will probably be less frequent. So frequent npm updates may not be your problem. The problem may be that npm updates are not sticking (or working at all) for you for whatever reason.
On the other hand, if you are using npm v7.x, it's a recent release that has been undergoing bug fixes every few days, but that is very likely to slow waaaay down. So one solution may be to just wait another week or two and the updates will be less frequent. (They may already be much less frequent than the were even last week.)
All that said: A blunt hammer solution would be to update npm as the first step in your build process. If you run npm run build as your build step, update package.json to add npm install -g npm && at the front of your build script. If you want to tolerate the npm update failing, you can change && to || but then the message you want to go away will still show up if the npm installation/update fails.
If your build process involves installing Node.js, then putting npm install -g npm after the Node.js installation is the way to go. Node.js ships with npm and it is exceedingly likely that the version that ships with Node.js is not the most recent version.
Related
This question already has answers here:
npm WARN deprecated tar#2.2.2: This version of tar is no longer supported, and will not receive security updates. Please upgrade asap
(4 answers)
Closed 1 year ago.
npm WARN deprecated tar#2.2.2: This version of tar is no longer supported, and will not receive security updates. Please upgrade asap.
changed 67 packages, and audited 68 packages in 7s
4 packages are looking for funding
run `npm fund` for details
2 high severity vulnerabilities
Some issues need review, and may require choosing
a different dependency.
Run `npm audit` for details.
This kind of problem is quite common for npm users. Your package.json file mentions multiple npm packages you need. And, each of those package's package.json file in turn refers to other packages, and so on. Somewhere in there some package refers to version 2.2.2 of tar. But the current version of tar is 6.2.2.
You can, as the error message says, run npm audit to find the offending package: that is, the package that wants the old version of tar (tar#2.2.2).
How to try to fix this?
If it's your package.json that loads tar#2.2.2 try doing these two commands.
npm remove tar --save
npm install tar --save
to get the latest.
Try running npm update --save. It will examine your nest of npm packages, and bring them up to more recent versions. That may, or may not, replace the offending package with a more recent version. It does this by updating a file called package-lock.json containing the explicit versions. If that doesn't work ...
Try running npm audit again to see what the situation is. Then, try npm audit --fix . If that doesn't work ...
File an issue on the github repository of the offending package asking for an update.
Look for another package with the same functionality as the offending package and replace it.
Decide you will live with the warning. (If your software is used in production, that may be unwise, because cybercreeps.)
Ask another question here and mention the offending package.
Everytime I do npm install after cloning a github project OR install packages on my local system for my practice projects, there are always around 20+ vulnerabilities.
But the guys in youtube tutorials always have 0 vulnerabilities.
I even reinstalled npm but it didn't change anything
If you are following an old video, you are likely installing old packages. Therefore it's pretty common to have vulnerabilities.
If you want the warnings to disappear, you can try to remove #version in your packages inside package.json and then run npm i again. Or, as bogdanoff says, run npm update instead.
But be careful: packages may behave differently from the video when updated.
I'm sure others have this workflow, so I must be missing something here.
How does one go about developing a new version of a package, linking it to test in another app, and then installing another (unrelated) package?
What I've done:
Run git clone git#package-to-update && cd package-to-update.
Edit package, update package-to-update/package.json version to 2.0.0.
Update my-app/package.json to use package-to-update#2.0.0.
cd package-to-update && npm link && cd my-appp && npm link package-to-update.
Test out my-app, see that package-to-update#2.0.0 resolves the issue, have a small party.
Push to package-to-update's upstream, create a merge request, and wait for maintainers to merge in my changes.
Use my local, linked version in the meantime as it's required for the feature I'm working on.
Notice I need another package other-unrelated-package in my-app.
Run cd my-app && npm install other-unrelated-package.
NPM fails because it's trying to pull package-to-update#2.0.0, which is not yet published.
Cry.
Is the only option here to run the following process every time you want to npm install?
Downgrade package-to-update in my-app/package.json.
Run npm install other-package.
Run npm link package-to-update.
Upgrade package-to-update in my-app/package.json".
I generally only use npm link for development. If I want to use a local version and not have to deal with re-linking, I install it by path rather than by version.
npm install /file/path/to/your/module
Then you'll end up with a file: URL like this in your package.json:
"slug": "file:../../slug"
Subsequent npm install won't search the registry in that case. (Since it will avoid the registry on future npm install runs, it also means you need to remember to change it back to the registry when the version with your patch is released!)
I haven't tested, but this method may require that you only care about it as an immediate dependency and not a dependency of another dependency. Based on your workflow above, that seems to be the case, but mentioning it here for other folks.
Assume all references in package.json are ^1.0.0 and I only bump the patch version.
I have A dependent on B dependent on C: A > B > C. I restore A and notice that the version of C I get is published after B. I expected the latest version of C that was published before B would be restored, but I actually got a version of C published after B.
I then published a vacuous patch of C and tried to upgrade A expecting to see the new version of C. However nothing changed; The version of C restored with A was the same version I got before I published a new version of C.
So, does NPM consider when packages were published when restoring dependencies of the form ^1.0.0?
As of npm#2.6.1, the npm update will only inspect top-level packages. Prior versions of npm would also recursively inspect all dependencies. To get the old behavior, use npm --depth 9999 update.
I'm running 6.4.1 so I was not getting the recursive behavior by default. Using the depth flag, I see C is updated to the new version.
However, that still doesn't explain why a version of C published after B was synchronized in the first place; When I first sync, even if I don't pass a depth flag, NPM has to recurse all dependencies. During that initial sync, what policy is it applying?
Now, if I delete the node_modules folder and run npm install I consistently get the new version of C. It's as if npm has remembered that I previously ran npm update with the depth flag however I find no record that I did that in packages.json as C is not listed in A's packages.json.
The behavior of npm makes more sense if I assume its designers were trying to reduce network traffic to npm.org.
npm install > v2.6.1 will satisfy indirect dependencies using the cache if possible even if more recent satisfactory versions have been published to npm.org; npm install will not check if there are more recently published versions of cached packages.
There are two ways to force npm to check the server for the most recent package versions: (1) use --depth 9999 or (2) delete the cache using npm cache clear --froce.
I think npm publish should locally cache the new package...
Is there any way we can suppress not to look for new versions during npm install. I know we can remove it from packages.json but doing the same thing in every dependent packages can quite become a challenge. The current problem i have is our company doesn't allow us to pull from public domain unless they are accepted and added to our private repository. Every time we add all the packages and after couple of days if we run npm install it will fail since a new minor or major version is released and we don't have it in our repository.
UPDATE Just recently Npm release npm ci command especially for such purposes. It strictly follows the package-lock.json file
I think starting with npm5 you have a lock file which solves that problem. In addition you could try npm shrinkwrap command, which is a bit older approach, it creates the shrinkwrap.json file with exact version of packages and next time npm will use only this versions.