Surprises around `resolutions`

[borekb]

I encountered a few "surprises" around resolutions – not sure if those are expected but since I couldn't find them mentioned on GitHub yet, here they go.

Context

We're using graphql@14 in our project but one of the deep dependencies has a peerDependency on graphql@15, which results in a warning like this:

➤ YN0060: │ @company/my-package@workspace:my-package provides graphql (pc69a0) with version 14.7.0, which doesn't satisfy what @graphql-codegen/typescript-operations and some of its descendants request

The actual package that has this peerDependency is relay-compiler@10.0.1. Since we cannot upgrade graphql in our project, the "solution" (though not great) is to downgrade relay-compiler to 9.x which has peerDependency on graphql@14.

--save / -s doesn't work

I ran this command:

yarn set resolution --save relay-compiler@npm:10.0.1 9.1.0

This updated yarn.lock like this (will be important later):

"@graphql-tools/relay-operation-optimizer@npm:^6":
  version: 6.2.4
  resolution: "@graphql-tools/relay-operation-optimizer@npm:6.2.4"
  dependencies:
    relay-compiler: 10.0.1

"relay-compiler@npm:10.0.1":
  version: 9.1.0
  resolution: "relay-compiler@npm:9.1.0"
  dependencies: ...

But it didn't affect project-level package.json – I expected to find resolutions field there. According to this Discord reply, -s isn't implemented yet. Fair enough but I couldn't find the info here on GitHub so just want to mention it.

resolutions field in package.json doesn't update yarn.lock?

Since I wanted to have a mention of a version mapping in package.json and not just in yarn.lock, I updated the manifest manually:

{
  "name": "@company/project-root",
  "resolutions": {
    "relay-compiler": "9.1.0"
  }
}

I then reverted yarn.lock (I got rid of the changes done by yarn set resolution) and ran yarn (install).

At this point, I expected the yarn.lock to look exactly like above but this was the result instead:

"@graphql-tools/relay-operation-optimizer@npm:^6":
  version: 6.2.4
  resolution: "@graphql-tools/relay-operation-optimizer@npm:6.2.4"
  dependencies:
    relay-compiler: 10.0.1

"relay-compiler@npm:9.1.0":
  version: 9.1.0
  resolution: "relay-compiler@npm:9.1.0"
  dependencies: ...

The key point is that @graphql-tools/relay-operation-optimizer depends on relay-compiler@10.0.1 but this version 10.0.1 is nowhere to be found in the lockfile – the only key there is "relay-compiler@npm:9.1.0".

I guess in this case, Yarn consults both yarn.lock and package.json#resolutions to find out how to resolve relay-compiler but it feels strange to me – I'd expect the mapping to be obvious just from the lockfile itself.

---

Again, not sure if those are issues or expected behavior but they surprised me.

[arcanis]

resolutions field in package.json doesn't update yarn.lock?

This is expected - the resolutions field only has effect while it's there. It's important, otherwise your ranges would be "eternally" locked to likely incompatible range resolutions.

--save / -s doesn't work

Indeed, we should remove this flag from the documentation for the time being (or implement it) 🤔

[borekb]

@arcanis thanks for the explanation. I get what you're saying but it still feels strange that resolutions vs. yarn set resolution lead to two different end states of our source files (although the actual installation will be the same, at least I hope 😄).

Theoretically, could yarn set resolution update only the package.json manifest instead of writing to yarn.lock? That way, both ways would be equivalent.

[arcanis]

Theoretically, could yarn set resolution update only the package.json manifest instead of writing to yarn.lock? That way, both ways would be equivalent.

No; the resolutions field and yarn set resolution are two different things. The first is a core-supported feature in itself, the second is meant to do exactly what it does: assign a new resolution to the lockfile. They share the same name because resolution is unfortunately a bit too generic, but they have different purposes.

[arcanis]

Reopening for --save

[borekb]

Oh, so the two are two different things? Even though the --save is currently not implemented, its docs say this:

If you wish to make the enforced resolution persist whatever happens, add the -s,--save flag which will also edit the resolutions field from your top-level manifest.

This makes intuitive sense to me but it's possible that this docs suggest something that couldn't work / is wrong.

[yarnbot]

Hi! 👋

This issue looks stale, and doesn't feature the reproducible label - which implies that you didn't provide a working reproduction using Sherlock. As a result, it'll be closed in a few days unless a maintainer explicitly vouches for it or you edit your first post to include a formal reproduction (you can use the playground for that).

Note that we require Sherlock reproductions for long-lived issues (rather than standalone git repositories or similar) because we're a small team. Sherlock gives us the ability to check which bugs are still affecting the master branch at any given point, and decreases the amount of code we need to run on our own machines (thus leading to faster bug resolutions). It helps us help you! 😃

If you absolutely cannot reproduce a bug on Sherlock (for example because it's a Windows-only issue), a maintainer will have to manually add the upholded label. Thanks for helping us triaging our repository! 🌟

[noahnu]

What does a "--save" look like? I was playing around with adding save functionality, and the main issue is that if you're setting a resolution for a transitive dependency, you need to specify the full path as the resolution key in the package.json. We can't fallback to globs because that's been removed in yarn v2 (unless it were to be added back?). Is the idea to only support saving for direct dependencies, or do we need to somehow generate the patterns?

I took a stab and trying to generate the patterns, however I don't think there's an existing function which given a descriptor, lists all packages that reference that descriptor? Also ran into an issue comparing descriptors because the npm: protocol is optional, but is not inferred when generating descriptor hashes (ended up re-generating the hashes).