Develop Reference

Auditing packages brings back more errors

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.

Npm Package Install Problem (found 23 vulnerabilities)

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.

Deleting `package-lock.json` to Resolve Conflicts quickly

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

Difference between `npm install` and `npm audit` counts?

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.

Satisfying peerDependencies with devDependencies in npm3

So NPM 3 has removed automatic resolving of peer dependencies which is great, however in the scenario of developing a plugin/library to be consumed by an application elsewhere if I make the underlying library use peerDependencies which is the correct notion here, it means if anyone wants to work on that library they need to manually resolve all dependencies.
So rather than having them do that it seems logical that I could put the same dependencies into devDependencies to satisfy the local development scenario, so anyone consuming it would need to explicitly satisfy the peers, anyone developing the library further would get the peer dependencies for free via the devDependencies.
So the question is, is there anything wrong with that? as I can find very little info on how to sensibly handle peerDependencies in NPM3 in any automatic fashion.
=== Update ===
As mentioned in the comments, when I tried doing things this way it is not compatible with earlier versions of npm, so npm >= 3.0 work fine with this approach and it satisfies the criteria automatically for a developer to check out npm install and be productive, however if you were to do this on an earlier version of NPM it blows up around peer dependencies not met and does not seem to work.
I post this as I hope this incompatibility with earlier versions is somehow down to my incompetence in some way so I can both support ease of development for people who just want to npm install on this package to develop for it, but also previous versions. So if you know a better way or a way around this or other issues this introduces please speak up.

I was asked to post this as the answer so here you go:
As mentioned in the comments, when I tried doing things this way it is not compatible with earlier versions of npm, so npm >= 3.0 work fine with this approach and it satisfies the criteria automatically for a developer to check out npm install and be productive, however if you were to do this on an earlier version of NPM it blows up around peer dependencies not met and does not seem to work.
I post this as I hope this incompatibility with earlier versions is somehow down to my incompetence in some way so I can both support ease of development for people who just want to npm install on this package to develop for it, but also previous versions. So if you know a better way or a way around this or other issues this introduces please speak up.