Add strictPeerDeps, override ERESOLVE if not true

[isaacs]

In the overwhelming majority of cases in the wild, a peer dependency
conflict that results in an ERESOLVE can be fixed by using the
--force flag.

However, this has other side effects (causing npm audit fix to install
semver-major fixes, blowing away file collisions, etc.) which might not
be desirable. Also, since it's opt-in, it means that users have to run
the install twice for something where we're pretty sure what the right
course of action is.

Let's just make that particular override the default, and reduce most
ERESOLVE errors from a crash to a warning.

(Also, a dumb fix for vuln, should probably pull that in regardless of where we land on this.)

cc: @MylesBorins

[MylesBorins]

I floated this patch locally and attempted to reify two known failing modules radium and serialport. Both of those modules now reify without error 🎉

I'm a huge fan of this change, it will give the community some time to adjust and update repos.

[ljharb]

@isaacs does this mean that invalid peer deps will no longer fail installs?

[ruyadorno]

@ljharb it should no longer fail most of the time. It's not the same as --legacy-peer-deps though, this change is just making it so that the current behavior we had with --force becomes the default, which means: it may still fail in the case of an unsolvable peer dep conflict but the vast majority of cases it will simply resolve the tree assuming the top-most declaration for that peer dep is the one that counts.

It will WARN with that big pretty-formatted ERESOLVE stack explaining precisely what the conflict is, nudging users/lib authors/maintainers (the ecosystem in general) into fixing these borked peer deps down the install tree.

[ljharb]

To be clear, when npm ls would return nonzero, I would want the install to always fail. Is that property still preserved?

[isaacs]

Yes, we'll be setting strictPeerDeps: true explicitly in npm ls.