Add more information to the resolutions example

Closes https://github.com/yarnpkg/yarn/issues/5759

I had serious issues trying to write something up that's short yet understandable. To me, this explanation makes sense, but honestly... it could probably do with some improvement so feel free to suggest them, no hard feelings!

Deploy preview for yarnpkg ready!

Built with commit 101dfb480ca821cf84445ce1a3c9e4be4ce25ef3

https://deploy-preview-970--yarnpkg.netlify.com

Just to see if I understand correctly. You mean if d2 imports a dependency, c, which depends on leftpad. Then the resolution c/**/left-pad would apply?

@shui91, that's an interesting case... I have not tested that. I would assume that's indeed what will happen, meaning d2 resolution to have a single version of left-pad would result in two versions of left-pad because c also enforces its own version of left-pad.

Will test this sometime later today as this got me very curious.

@StephanBijzitter any update on this?

Alright, just tested.

The structure of the test is as follows, where -> means "has a dependency on":

test-project -> dep-a -> dep-b -> dep-c -> [email protected] test-project -> jquery@^3.4.1

For test-project, the package.json is as follows:

  "dependencies": {
    "dep-a": "../dep-a",
    "jquery": "^3.4.1"
  }

And the lockfile is as follows:

[email protected]:
  version "3.1.1"
  resolved "https://registry.yarnpkg.com/jquery/-/jquery-3.1.1.tgz#347c1c21c7e004115e0a4da32cece041fad3c8a3"
  integrity sha1-NHwcIcfgBBFeCk2jLOzgQfrTyKM=

jquery@^3.4.1:
  version "3.4.1"
  resolved "https://registry.yarnpkg.com/jquery/-/jquery-3.4.1.tgz#714f1f8d9dde4bdfa55764ba37ef214630d80ef2"
  integrity sha512-36+AdBzCL+y6qjw5Tx7HgzeGCzC81MDDgaUP8ld2zhx58HdqXGoBd+tHdrBMiyjGQs0Hxs/MLZTu/eHNJJuWPw==

After adding the following resolution:

  "dependencies": {
    "dep-a": "../dep-a",
    "jquery": "^3.4.1"
  },
  "resolutions": {
    "dep-a/**/jquery": "3.3.1"
  }

The lock file changes to:

[email protected], [email protected]:
  version "3.3.1"
  resolved "https://registry.yarnpkg.com/jquery/-/jquery-3.3.1.tgz#958ce29e81c9790f31be7792df5d4d95fc57fbca"
  integrity sha512-Ubldcmxp5np52/ENotGxlLe6aGMvmF4R8S6tZjsP6Knsaxd/xp3Zrh50cG93lR6nPXyUFwzN3ZSOQI0wRJNdGg==

jquery@^3.4.1:
  version "3.4.1"
  resolved "https://registry.yarnpkg.com/jquery/-/jquery-3.4.1.tgz#714f1f8d9dde4bdfa55764ba37ef214630d80ef2"
  integrity sha512-36+AdBzCL+y6qjw5Tx7HgzeGCzC81MDDgaUP8ld2zhx58HdqXGoBd+tHdrBMiyjGQs0Hxs/MLZTu/eHNJJuWPw==

So dep-c, which requires 3.1.1 now gets 3.3.1, while test-project which requires ^3.4.1 still gets 3.4.1.

That all sounds good, until we change the dep-a/**/jquery into dep-a/*/jquery. I would've expected this change to mean "only enforce this on direct dependencies of dep-a (which would be dep-b), but instead something weird happened:

[email protected]:
  version "3.1.1"
  resolved "https://registry.yarnpkg.com/jquery/-/jquery-3.1.1.tgz#347c1c21c7e004115e0a4da32cece041fad3c8a3"
  integrity sha1-NHwcIcfgBBFeCk2jLOzgQfrTyKM=

[email protected]:
  version "3.3.1"
  resolved "https://registry.yarnpkg.com/jquery/-/jquery-3.3.1.tgz#958ce29e81c9790f31be7792df5d4d95fc57fbca"
  integrity sha512-Ubldcmxp5np52/ENotGxlLe6aGMvmF4R8S6tZjsP6Knsaxd/xp3Zrh50cG93lR6nPXyUFwzN3ZSOQI0wRJNdGg==

jquery@^3.4.1:
  version "3.4.1"
  resolved "https://registry.yarnpkg.com/jquery/-/jquery-3.4.1.tgz#714f1f8d9dde4bdfa55764ba37ef214630d80ef2"
  integrity sha512-36+AdBzCL+y6qjw5Tx7HgzeGCzC81MDDgaUP8ld2zhx58HdqXGoBd+tHdrBMiyjGQs0Hxs/MLZTu/eHNJJuWPw==

So as for your question: yes, that is exactly what will happen. And as for this weird behaviour, I'll create a separate bug report for that.

We should remove the globs from the documentation, they don't make sense.

• foo: will replace any instance of foo, anywhere
• foo/bar: will replace any instance of bar within dependencies called foo, anywhere

The glob patterns are unnecessary and mislead you into thinking that you can, for example, do something like "foo/bar/baz" - which isn't possible per Yarn's model (because bar is the same regardless of whether it's a dependency of foo or qux).

@arcanis

This is not true, see the example above in the comments. Maybe it's different for v2, but v1 does not operate the way you describe.

I know the v1, and the behaviour you describe doesn't have the effect you think. If you use the exact same range of jQuery in two different places (like the foo I mentioned), they'll share the overrides of bar/**/jquery even if only one of them is a dependency of bar. This is because our lockfile format doesn't support (by design) storing the same combination of name+range multiple times.

@arcanis

The glob patterns are unnecessary and mislead you into thinking that you can, for example, do something like "foo/bar/baz" - which isn't possible per Yarn's model (because bar is the same regardless of whether it's a dependency of foo or qux).

So you are saying that yarn does not respect a resolution like "foo/bar/baz": "1.0.0" ? Do I get you correct ?

I thought yarn would do: "I will install [email protected] for every chilld of bar when bar is a direct child of foo".