Need of better understanding of npm behavior (>= 7)

Question

I do have problems to understand the 'new' npm behavior in some points:

1. npm >= 7 is more strict about peer dependencies. I already posted a question for this here. But I still don't understand completely the benefit of the 'new' behavior. I hope to get more practical explanation. Now every of my repositories throws these error doing npm install and as far as I understand, I can't really do anything about this behaviour, as the maintainer should have updated there packages. But in real life there will never be the point where all packages are up to date.

2. I do get multiple vulnerabilites reports, but npm audit fix mostly doesn't fix any vulnerability. Here the same problem: It can only be handled by the maintainer, so I can't do anything. So how should I handle those reports practically?

3. Similar thing with deprecation messages. As an example sockjs-node which is using uuid 3.4.0 - latest is 8.3.2. But the maintainer doesn't update the package, as there is no need for that in his view. So here the same thing: The maintainer is the only one who can solve the problem.

In all of these cases I would like to know how to handle those things. What are you doing? In my CI pipeline I do get many deprecation messages and I must use --legacy-peer-deps which practically means I have to use npm 6 and I also get many vulnerabilities reported.

So it will never be possible to get a "clean" install, right?

What is the value of reports/messages, if they are always there so they get 'normal' and I have to ignore them?

Answer 1

According to the npm announcement for v7:

Automatically installing peer dependencies is an exciting new feature introduced in npm 7. In previous versions of npm (4-6), peer dependencies conflicts presented a warning that versions were not compatible, but would still install dependencies without an error. npm 7 will block installations if an upstream dependency conflict is present that cannot be automatically resolved.

The benefit of the new npm behaviour is that you have to intentionally choose to force installation if there are mismatched peer dependency versions, which is about bringing developer attention to potential dependency issues instead of merely printing warning messages in the logs, which are prone to getting ignored.

In general, it shouldn't be the case that you always have errors with peer dependencies. It may be the case (as it is with Angular applications, for instance) that peer dependencies will be mismatched when upgrading a major version (the core libraries need to be upgraded, and then the plugins, etc...). But if you are always getting peer dependency errors, it suggests that either one of the dependencies is inappropriately strict in the version it needs, or the dependency is out of date, or the dependency has not yet been updated to match the version of its peer.

Your options in these circumstances should be to (1) downgrade listed peer dependencies until those dependencies using them are updated, (2) upgrade dependencies to keep up with versions listed as peers, (3) force installation using npm i --force or npm i --legacy-peer-deps, or (4) open an issue or create a PR for open source projects whose peer dependencies are too strict or who need to be updated to keep up with the latest version of their peer.

Regarding the use of npm audit, how you handle the reports depends on your needs. If, for instance, you want to automatically ensure that no critical vulnerabilities are included in your application, there are various flags (documented here). For instance, you could use npm audit --audit-level=moderate to only surface vulnerabilities that are moderate or higher risks. You can also run npm audit fix --force to force fixing vulnerabilities at the risk of using incompatible dependencies.

In general, you do depend on maintainers to eliminate those pesky error messages (unless you're willing to risk lots of things breaking by --forceing your way through). So sometimes the right thing to do is just ignore the error messages and move on. Or, if you need to have greater confidence in your security posture, schedule some time every few months to review those vulnerabilities (or deprecations) until you're satisfied.

And, of course, there is always the option that is the most work, but is always possible: contribute to open source. If dependencies need updating, offer to make the PR and tests. If the maintainer refuses to update a deprecated library, there's always the option to fork and update it yourself. There are probably lots of people out there who would start using a forked library if it demonstrates a commitment to keeping its dependency chain clean.