addendum: overrides apply if value matches, as well as key

[isaacs]

Found a pretty serious problem with overrides while starting
implementation. Namely, it is in many cases impossible to determine
whether a node in a reified tree was subject to an override or not.

The edge case is described in this patch, and a fix proposed:

If a dependency matches the key in an overrides object or it
matches the "." value specifier, then the override ruleset will
apply.

By doing this, it prevents version-swapping, makes infinite regress even
more impossible, and ensures that the resulting package tree can always
be properly examined, without any out of band bookkeeping.

cc: @nlf

References

[ljharb]

Is there any negative consequence of this change - like, any lost capability or new caveats to be aware of as an end user?

[isaacs]

Is there any negative consequence of this change - like, any lost capability or new caveats to be aware of as an end user?

Just potential confusion.

For example, say you have a package.json like this:

{
  "dependencies": {
    "foo": "1 || 2"
  },
  "overrides": {
    "foo@1": {
      ".": "2",
      "bar": "1.2.3"
    }
  }
}

If you install it, and foo@1 || 2 from the dependencies results in foo@2.3.4, then it will still get bar@1.2.3 as an overridden dependency, because the . member matches foo@2.3.4, even though the foo@1 key clearly doesn't.

Far and away, the most common use case will be to lock down all versions of a given library within a project, like:

{
  "dependencies": {
    "foo": "1 || 2"
  },
  "overrides": {
    "react": "16",
    "react-dom": "16"
  }
}

so I do expect that this will be an edge case.