[bscphil]

Well said.

I would add that I think the devDependencies solution is underrated. Not using it is a bad practice. npm has a nice feature, `npm prune --production` which will remove all the dev dependencies for you resulting in a clean build of the program. You can easily have things set up so that none of the development dependencies that have all these audit issues are ever present on your production machines if you do things right.

Furthermore, if you have a project with end users, devDependencies allows you to make clear in your issue template that audit issues that don't show up in a production build are very likely to be false positives and will probably be closed without comment. If you aren't properly isolating your dependencies, you can't take advantage of this.

At the end of the day, as you say, the issue is largely with Node projects having too many dependencies and a large number of relatively minor issues that affect very specific use cases get reported. That's a hard ecosystem problem to solve, not necessarily something that indicates an inherent problem with npm audit; but if someone isn't using devDependencies, that alone could constitute an enormous improvement in their workflow.

[Vinnl]

If there's a vulnerability in Webpack (a devDependency) that injects malicious code into your bundle, `npm prune --production` won't save you.

[remram]

This is not a vulnerability (ie. security bug) it's an attack (ie. malicious).

[Vinnl]

It doesn't really matter how you call it; the problem is that there could be CVE's in your devDependencies that affect your production build, and pruning those dependencies after using them to create that build doesn't remove the risk.

[hinkley]

I'm currently using 'npm ci --prod', which means that they never get installed in the first place.

However it's incompatible with optionalPackages, so I'm carrying around some tertiary dependencies that are a small but noticeable fraction of the entire archive size.