[Feature] Interactive upgrade should respect resolutions

[mekwall]

• [ ] I'd be willing to implement this feature (contributing guide)
• [ ] This feature is important to have in this repository; a contrib plugin wouldn't do

Describe the user story

Currently when you run upgrade-interactive from the interactive tools it will ignore entries in resolutions and will recommend upgrades even though it wouldn't do anything due to the package being locked down by resolutions.

Describe the solution you'd like

Enable upgrade-interactive to take resolutions into account and use the versions listed in there.

Describe the drawbacks of your solution

I don't see any drawbacks with this feature.

Describe alternatives you've considered

I haven't found any alternative solutions to this other than just ignore the entries, but it makes the tool cumbersome to use.

[edvardchen]

@arcanis it seems easy to support. But what should we do? Adding another column to display the resolution version?

[patdx]

It sounds like in this situation, the developer has used the resolution field in a case where they never/rarely wants to update the package? But in this case, even if you accidentally accept the upgrade, nothing would actually change, because it is overridden by resolutions field, right?

I have often run into the "opposite" use case, where I use the resolutions field but still wish that package could participate in interactive upgrades. I use the interactive upgrade feature, think it upgraded the package, then realize later it did nothing (but I wanted it to do something). For example, I have a package.json like this:

{
  "private": true,
  "name": "mo",
  "resolutions": {
    "vite": "3.1.4"
  },
  "dependencies": {
    "vite": "3.1.4"
  },
  "packageManager": "yarn@3.2.4"
}

(My package.json also has various vite plugins with various vite dependency queries, but I will actually only ever use one version of Vite).

I used upgrade-interactive to upgrade Vite to 3.1.8, but the resolutions field did not change so nothing actually happened. After realizing the issue, I had to change the resolutions field manually and run yarn install again.

For this case, similar to the way that workspace dependency versions are automatically upgraded together:

https://github.com/yarnpkg/berry/blob/589e231c6f275c20ffa44119f25febce38840ad8/packages/plugin-interactive-tools/sources/commands/upgrade-interactive.tsx#L329

I think the most natural behavior would be to automatically upgrade the resolution versions when matching the version in packageJson.dependencies or packageJson.devDependencies,

For cases where the user wants the opposite behavior (eg, to disallow upgrades completely or constrain them to the allowed resolutions range), maybe there could be a setting somewhere to just hide the package in the upgrade-interactive UI, or facilitate some kind of interaction with yarn constraints feature. You could set a constraint for the package in yarn constraints and upgrade-interactive would try to use this data point when suggesting a new package version.