I tried to install the package. But I saw this error.How to solve this problem ?
It means that there are 23 packages in your package.json (or dependencies of packages in your package.json) that have reported vulnerabilities. If you own the code base you could try to update the dependencies to newer versions and hope that the authors have released new versions with the vulnerabilities fixed. If you don't own the code then you should contact the person who does.
It means that there are packages in package-lock.json that have publicly-disclosed vulnerabilities in them.
How to correctly handle this will depend a lot of things. Easiest is probably to run npm audit fix which will fix all the ones that it can without introducing incompatible changes (as determined by semantic versioning, so it's far from a guarantee). That will update your package-lock.json in the process.
If there are vulnerabilities that cannot be fixed without introducing an potentially-incompatible change (again, as determined by semantic versioning), then you will have to do more than npm audit fix. Fortunately, npm audit fix usually gives you instructions. One thing it can't do for you, though, is test and fix any issues that result from the incompatible upgrades.
Related
I tried to fix some issues in my project by running npm audit fix
which didn't do much, however when I append --force flag the return result is worse than previously:
fix available via `npm audit fix`
10 vulnerabilities (2 moderate, 8 high) 😮💨
using the --force
fix available via `npm audit fix --force`
79 vulnerabilities (14 low, 23 moderate, 38 high, 4 critical) 🤯
I'd use yarn if I could however I can't. How else would one fix these with npm
or do I need to go into each one and do it manually?
Thanks in advance 🌚
First up, reason you can see more issues when you force is that updated package might legit still have more audit findings.
Please note that using --force is not always a good option, especially on an existing older code base, since forcing the dependency updates might introduce breaking change which will need code changes. If you are up for those then by all means force it.
Finally, there's no silver bullet approach to updating dependencies with audit findings. There may or may not be actual fixes available.
Generally speaking, yes auditing them one at a time, is a good idea. This way you can read the details of findings. Look at the repos and see what the fixes or repercussions of updating are.
Also, using Yarn doesn't necessarily help you with audit findings. Since yarn is just another tool to pull down the exact same lib versions.
I have a large react app in production and I'm wondering if its best to use fixed versions for my packages? I've heard that using the caret (^) is a good practice, but that seems to me that it would leave the application open to more bugs?
I've googled this issue quite a bit, and there seems to be a split between ^ and fixed versions. Is there a definitive answer somewhere in the (npm) docs on what approach to use?
During development you can choose whichever you're comfortable with, but I would recommend shrinkwrapping just before you begin testing the app, before going into production. Lock down the dependencies with:
npm shrinkwrap
This command repurposes package-lock.json into a publishable npm-shrinkwrap.json or simply creates a new one. The file created and updated by this command will then take precedence over any other existing or future package-lock.json files. For a detailed explanation of the design and purpose of package locks in npm, see npm-package-locks.
That way you can leave the dependencies declared in package.json as they are (tilde/caret), but the exact versions declared in npm-shrinkwrap.json will only ever be used when npm installing.
I've personally had a problem just before going into production, when a dependency declared with ~ (the stricter one) was updated and introduced a bug (which shouldn't happen for a patch/bug fix). It's only ever happened once, but I would't want to tempt fate.
You can always update your npm-shrinkwrap.json by first doing npm update <package_name> specifying the package that needs updating, then re-doing npm shrinkwrap to update the existing npm-shrinkwrap.json.
...and don't forget npm ci
In a team set up, usually, I have faced merge conflicts in package-lock.json and my quick fix has always been to delete the file and regenerate it with npm install. I have not seriously thought about the implication of this fix because it has not caused any perceivable problem before.
Is there a problem with deleting the file and having npm recreate it that way instead of resolving the conflicts manually?
Yes, it can and will affect all the project in really bad way.
if your team does not run npm install after each git pull you all are using different dependencies' versions. So it ends with "but it works for me!!" and "I don't understand why my code does not work for you"
even if all the team runs npm install it still does not mean everything is ok. at some moment you may find your project acts differently. in a part that you have not been changing for years. and after (probably, quite painful) debugging you will find it's because of 3rd level dependency has updated for next major version and this led some breaking changes.
Conclusion: don't ever delete package-lock.json.
Yes, for first level dependencies if we specify them without ranges (like "react": "16.12.0") we get the same versions each time we run npm install. But we cannot say the same about dependencies of 2+ level deep (dependencies that our dependencies are relying on), so package-lock.json is really important for stability.
In your case you better do next way:
fix conflicts in package.json
run npm install
As easy as it looks. The same to yarn - it fixes lockfile conflict on its own. The only requirement here to resolve all the conflicts in package.json beforehand if any.
Per docs npm will fix merge conflicts in package-lock.json for you.
[Upd from 2021] important! If you use some library already and npm/GitHub account of its maintainer is hacked. And new version with malicious code inside is released. And you have package-lock.json intact. You will be fine. If you drop it you are in trouble.
Yes it can have bad side effects, maybe not very often but for example you can have in package.json "moduleX": "^1.0.0" and you used to have "moduleX": "1.0.0" in package-lock.json.
By deleting package-lock.json and running npm install you could be updating to version 1.0.999 of moduleX without knowing about it and maybe they have created a bug or done a backwards breaking change (not following semantic versioning).
Anyway there is already a standard solution for it.
Fix the conflict inside package.json
Run: npm install --package-lock-only
Check out this link for more info:
https://docs.npmjs.com/cli/v6/configuring-npm/package-locks#resolving-lockfile-conflicts
I know it's an old question but for future seekers, you can also use npm-merge-driver which try to automatically resolve the npm related files' merge issues.
Just install it globally npx npm-merge-driver install --global. You can read more about it here npm-merge-driver
Edit: Just want to warn people, who are interested in using above package, that sometime it can behave erratically and difficult to remove. So although it is a useful tool, it still need some work.
Edit: This repository is now archived and read only.
npm i --force does the work for me
After the recent addition of npm audit (for auditing dependencies) I noticed a huge discrepancy between how many packages are added (installed in node_modules) and how many are audited by npm. Here's an example:
Here are my questions:
Am I correct that 281 is the total number of packages installed?
Why is npm auditing so many more packages than the ones in my project?
It makes sense to me that npm might have to go back out and audit other package versions if it finds a vulnerability, but in this case it found 0 vulnerabilities so why the additional work?
UPDATE:
I think there's a little confusion about top-level vs sub dependencies. Run the following commands to reproduce a similar discrepancy:
mkdir test-npm-count-discrepancy
cd test-npm-count-discrepancy
npm init
npm i standard-version
Notice that (at the time of writing this) 200+ dependencies are added (i.e. standard-version and all its sub dependencies) but 1000+ packages are audited. Just to re-iterate, the main question from above is "why is npm auditing more packages than what's actually installed?".
For the first question:
- the community, without a link to something like a dependency list or your package.json, wouldn't really be able to say so. However, if in your package file only has a few, then it still is normal most of the time. You may have installed 12 yourself, but NPM auto-installs most, if not all, dependencies for your app's dependencies for you. It helps things speed up your workflow.
For the second question:
- as mentioned in my response to the first question, it is auditing both the ones you installed and the ones that were installed automatically so that the ones you installed work properly.
For the third question:
- It always checks for vulnerabilities marked by developers so you can have the latest version which is, most of the time, the least buggy, the most functional, and most secure.
Edit:
The whole point of npm install is to update current dependencies and install new ones to the directory. The point of npm audit is to check for dependencies that have updates marked to fix security issues.
Edit 2:
I think I've got it: it could be auditing the installed dependencies for production, your dependencies, and the dev-dependencies to warn you that one of your dependencies was built insecurely by the developer.
My Node version : v0.12.2
My npm version: 2.7.4
I ran the following command: npm install gulp -g
Should I care ? I get these warnings:
C:\Users\Maddy\Desktop\PublicServer\skill_tests>npm install gulp -g
npm WARN deprecated graceful-fs#3.0.8: graceful-fs v3.0.0 and before will fail on node releases >= v7.0. Please update to graceful-fs#^4.0.0 as soon as possible. Use 'npm ls graceful-fs' to find it in the tree.
npm WARN deprecated minimatch#2.0.10: Please update to minimatch 3.0.2 or higher to avoid a RegExp DoS issue
npm WARN deprecated minimatch#0.2.14: Please update to minimatch 3.0.2 or higher to avoid a RegExp DoS issue
npm WARN deprecated lodash#1.0.2: lodash#<3.0.0 is no longer maintained. Upgrade to lodash#^4.0.0.
npm WARN deprecated graceful-fs#1.2.3: graceful-fs v3.0.0 and before will fail on node releases >= v7.0. Please update to graceful-fs#^4.0.0 as soon as possible. Use 'npm ls graceful-fs' to find it in the tree.
Those error warnings are not a major issue. I get the same warnings when I install gulp. I have been using it for a while. It has to do with the libraries that support gulp. Gulp has dependencies and those dependencies are "packaged" together to create gulp. For example lodash is a javascript library that has a lot of array utilities. But lodash is maintained by the person who developed it
If you look in the node_modules folder you can see all the dependencies that make up gulp. I just pointed out lodash because you can find the link here and review it yourself. Gulp is not one javascript library it's a compilation of several projects that make up one tool.
Since npm has no kind of a rating system -- or anything remotely similar, there are a lot of "old" packages out there that refer to other "old" packages.
And, for the most part, that is fine.
For the most part being the key phrase.
Once in a rare while there may be a breaking change to node which causes one of these old packages to fail and you can get a cascading error upwards. However, it doesn't seem to happen too often -- I've only run into it once.
The bottom line is: Unless you are able to maintain the packages, there isn't really anything you can do about it.
All of these are warnings, which means you should be fine. If you encounter an error run:
npm list
which will give you a list of dependencies and packages. Generally speaking, these have to be updated by the author. So you if it's mission critical give them a ping on their repos or find alternatives that are maintained.