[FEATURE] Create RFC for Yarn Resolutions

[karlhorky]

What / Why

Not sure if this is the right way to do this, but I wanted to create a placeholder issue for the eventual creation an RFC for Yarn Resolutions.

As @isaacs mentioned in #39 (comment) (emphasis mine):

I think a pretty good plan is maybe to ratify this, de-ratify the current overrides, and instead add a new RFC to implement yarn's resolutions with the same syntax and logic as yarn uses. Better to walk the existing cowpath than create another one.

References

• Original Package Overrides RFC (accepted): Package overrides #27
• New Package Overrides RFC (now abandoned) package.json overrides option #39
• Newer acceptDependencies RFC acceptDependencies package.json field #72
• Related "Multi Target Proposal" RFC: Multi target proposal #28
• Yarn Resolutions: https://yarnpkg.com/lang/en/docs/selective-version-resolutions/

[ruyadorno]

Putting this back on the agenda since I think we might want to close it given that #72 was ratified and implemented.

[karlhorky]

Oh nice, an acceptDependencies field! In which version of npm can I use this?

Does this cover common cases of Yarn Resolutions? For example:

1. I want to upgrade all versions of minimist at any level to version 0.2.1:

{
  "resolutions": {
    "minimist": "0.2.1"
  }
}

It looks like acceptDependencies covers this use case.

2. I want to upgrade minimist to 0.2.1, but only when it's a dependency of mkdirp. In other cases, I want to use version 1.2.5.

{
  "resolutions": {
    "**/mkdirp/minimist": "0.2.1",
    "mkdirp": "1.2.5"
  }
}

I'm not sure whether acceptDependencies would cover this common case.

These are just a couple that I have dealt with a lot. Maybe @arcanis could chime in with other common use cases for Resolutions.

---

Taking a look at the example of acceptDependencies, it's not immediately clear to me whether anything other than the most simple case is supported:

{
    "name": "my-node4-package",
    "engines": {
        "node": ">=4"
    },
    "dependencies": {
        "make-dir": "^1.3.0"
    },
    "acceptDependencies": {
        "make-dir": "2.x - 3.x"
    }
}

[isaacs]

This is the direction we're likely going: #129

Expect an update to this RFC to make some changes this week and explore a lot of the edge cases.

The result of last week's deep dive was that we really cannot reasonably go the route of implementing Yarn's resolutions field, basically for all the same reasons that led yarn2/berry to abandon it.

[arcanis]

I'm not sure what you mean, we didn't abandon it. It's implemented in v2 the same as in v1, except that the syntax was made less ambiguous 🤔

[isaacs]

Ah, ok, my mistake. I thought it was replaced by a new thing.

[wesleytodd]

@arcanis I think maybe that was phrased incorrectly, I assume @isaacs was referring to the new methodology for applying rules using prolog? The new docs I think are here right? https://yarnpkg.com/configuration/manifest#resolutions

Which is different from the prolog stuff? I don't see that documented, maybe you can link to that?

EDIT: Sorry @isaacs your messaged popped in as I submitted this comment.

[arcanis]

The prolog constraints are an entirely different feature that has nothing to do with resolutions.

Glob patterns were discontinued as a syntax because they had no sensible additional effects - users could just omit them and it worked just fine.

[wesleytodd]

Glob patterns were discontinued as a syntax because they had no sensible additional effects - users could just omit them and it worked just fine.

Good to know.

The prolog constraints are an entirely different feature that has nothing to do with resolutions.

Do you have docs or discussions which we could go read? I am very interested in the learnings from the process here. Thanks in advance for any help you can provide!

[isaacs]

Glob patterns were discontinued as a syntax because they had no sensible additional effects - users could just omit them and it worked just fine.

Ah, that's great to hear! I was under the (incorrect?) assumption that foo/bar would only match if bar was a direct dependent of foo, where as foo/**/bar would match if bar was anywhere in the foo branch of the dependency graph. Is that mistaken?

If so, wow, extremely good call removing the globs, because it's clearly somewhat confusing. It would also mean that we probably can translate yarn resolutions into npm overrides, and support either syntax. There are a few things you can do with overrides that I don't think quite map in the other direction, but we'll see once this RFC fully solidifies.

[karlhorky]

This is the direction we're likely going: #129

@isaacs oh nice, really awesome!

Looks like npm Overrides cover all of the use cases Yarn Resolutions cover and more! Really like the version specifiers and calling out the "exceptions".

Simple

• any minimist@0 dependencies should be pinned to minimist@0.2.1
• any webpack@1 and webpack@2 dependencies should be pinned to webpack@2.7.0
• any x@1.2.3 dependencies should be pinned to x@1.2.4

{
  "overrides": {
    "minimist@0.x": "0.2.1",
    "webpack@1.x || 2.x": "2.7.0",
    "x@1.2.3": "1.2.4"
  }
}

Matching Transitive Dependencies (sub-dependencies)

• replace all versions of x@1.x with version 1.2.3 - but only when used as a dependency of y@2.x

{
  "overrides": {
    "y@2.x": {
      "x@1.x": "1.2.3"
    }
  }
}

Exceptions

• force all versions of react to be 15.6.2
• except when used by the dependencies of tap, where react@16 will be used

{
  "overrides": {
    "react": "15.6.2",
    "tap": {
      "react": "16"
    }
  }
}

[darcyclarke]

I'm going to close out this issue as we've moved the conversation of overrides/resolutions to the RFC (#129 ) specifically.

[karlhorky]

Ok, thanks everyone! Really excited about npm again! 💯

[darcyclarke]

Thanks @karlhorky ❤️ 😄 We're excited to keep building something awesome with your help/input.