Implements stable resolution

[arcanis]

This PR implements "Stable resolution". In a few words, it changes the resolution algorithm so that we always pick the highest resolution possible that's also the lowest from any range in the tree. For example, if a package Foo has versions 1.0, 1.1, 1.2, and if a project has dependencies X and Y that respectively require Foo@^1.0 and Foo@^1.1, then the only version Yarn will install will be 1.1 (not 1.0, because 1.1 already fulfills ^1.0, and not 1.2, because it's not the lowest version supported by any range).

This change would prevent malicious packages from spreading across the ecosystem, by requiring popular JS tools to "vet" them first by introducing them into their own dependencies.

I have an article about this being written, will update when finished.

edit: It unfortunately seems this isn't compatible with the ecosystem (see the E2E tests at the end, it's about 50/50, with many packages breaking because they rely on old dependency ranges that they aren't actually compatible with), so it's a bit blocked at the moment 😕

[quanru]

@arcanis Hi~ Awesome implementation, I've also been investigating golang's Minimal Version Selection recently
, unfortunately the current ecology of npm package is not suitable for this strategy for the reasons you mentioned. What If we use the time-based resolution strategy like pnpm, can we strike a balance between stability and availability?

• Time-based resolution mode pnpm/rfcs#2
• feat: time-based resolution mode pnpm/pnpm#5238