Normalizes dependencies

[arcanis]

What's the problem this PR addresses?

Dependencies sometimes weren't normalized (with the npm: protocol), which made it difficult to know what input to expect in which place.

How did you fix it?

All dependencies must now be normalized prior to being returned by resolvers or hooks. The configuration class now provides helpers to this effect.

I changed the dependencies format from a Map<DescriptorHash, Descriptor> to a Record<string, Descriptor> so that resolvers can modify the descriptor without changing its key in the map, which would prevent followup consumers from accessing the dependencies (an alternative would have been to use an old DescriptorHash with a new Descriptor, but this seemed a confusing and bad idea).

A compatibility layer in the lockfile should make the transition fairly painless from an end user point of view.

Checklist

• I have read the Contributing Guide.

• I have set the packages that need to be released for my changes to be effective.

• I will check that all automated PR checks pass before the PR gets reviewed.

[merceyz]

I changed the dependencies format from a Map<DescriptorHash, Descriptor> to a Record<string, Descriptor> [...]

What's preventing you from making it a Map<string, Descriptor>?

[arcanis]

What's preventing you from making it a Map<string, Descriptor>?

Nothing technically speaking, it's more a matter of semantics. Since with this diff the dependencies are "static" for a same resolver, I feel like it makes more sense to use an object and let resolver functions use e.g. destructuring, than having to go through the get method w/ static names (I know we already do it with Configuration#get, but that's something I'd like to change as well when I get time).

Using a map would be more backward compatible, but given that I'm changing a few other things in resolvers' interfaces anyway (like getSatisfying, in #4302), I'd tend to pick the cleaner approach rather than adding (admittedly small) legacy.

[skoging]

I think this change has caused some weirdness with peer dependency validation:

❯ yarn explain peer-requirements pbf332
➤ YN0000: react-scripts@npm:5.0.1 [ffbb4] provides webpack@npm:5.72.0 [57b3f] with version 5.72.0, which doesn't satisfy the following requirements:

➤ YN0000: fork-ts-checker-webpack-plugin@npm:6.5.2 [62680] → >= 4     ✓
➤ YN0000: react-dev-utils@npm:12.0.1 [f1e1c]               → npm:>= 4 ✘

➤ YN0000: Note: these requirements start with react-dev-utils@npm:12.0.1 [f1e1c]

The npm:>= 4 is considered not met, while >= 4 is met.

First of all this is clearly incorrect, and also it does not seem to be fully normalized. Shouldn't both be npm:>= 4 now?

[arcanis]

Peer dependencies aren't supposed to go through this normalization, because they only support Semver ranges (the define compatible versions, not the source from which those versions must be obtained) 🤔

Do you have a minimal repro I can copy/paste?

[skoging]

Did some more testing and it appears to be caused by packageExtensions:

  react-dev-utils@*:
    peerDependencies:
      typescript: ">= 2.7"
      webpack: ">= 4"

So these extensions seem to be normalized, when they shouldn't be?

[skoging]

yarn create react-app and adding these packageExtensions to .yarnrc.yml should reproduce this issue

[paul-soporan]

@skoging The issue has been fixed in #4588.