Upgrade-interactive should also edit resolutions in package.json

[marcofugaro]

Do you want to request a feature or report a bug?
Bug (behavioral)

What is the current behavior?
Whenever I run yarn upgrade-interactive --latest it asks me if I want to update also resolutions:

I update them, but yarn doesn't modify their version in package.json.
So when I run yarn upgrade-interactive --latest again, they are still there and yarn asks me if I want to upgrade them again.

If the current behavior is a bug, please provide the steps to reproduce.
Have this in your package.json

"resolutions": {
  "**/webpack": "4.0.0-beta.2",
  "**/webpack-dev-server": "3.0.0-beta.2"
}

and run yarn upgrade-interactive --latest

What is the expected behavior?
Yarn should also edit the resolutions in the package.json (like it works with the dependencies) when you upgrade them.

Please mention your node.js, yarn and operating system version.
Node v9.5.0
Yarn v1.3.2
OSX High Sierra

[rally25rs]

@yarnpkg/core resolutions feels like a bit of a "grey area" in terms of expected behavior when used in conjunction with upgrade. Anyone have any suggestions as to the best way to handle this? Change any resolution that ends with the same package name as one being upgraded to be the version that was just upgraded to? I could imagine cases where you might not want that too though, like if you have multiple resolutions of the same package:

  "dependencies": {
    "left-pad": "2.0.0",
    "b": "*",
    "c": "*"
  },
  "resolutions": {
    "b/left-pad": "1.1.1",
    "c/**/left-pad": "1.1.2"
  }

then upgrading to left-pad@3 would update the direct dep, but you might not want it to tweak your resolutions.

[kaylie-alexa]

yeah I'm struggling to come up with the best solution for this, because I think of resolutions as more like a configuration similar to a webpack alias. It's not your actual direct dependency (although it does get installed similar to one 😿 ) and when you are adding a resolution you usually pinning it to resolve a bug, and upgrading them can get into weird edge cases like the case you mentioned. But at the very least, if it won't be auto-updated, we should remove it from showing in upgrade-interactive command.

[abkieling]

One issue I find is that yarn upgrade-interactive fails silently when there is an entry in the resolutions section. It should at least warn the user that it will not upgrade the dependency due to a conflicting configuration. I personally think it should upgrade the dependency and changed the version number in the resolutions section.

[RinMinase]

Any updates on this feature? Either letting the users know that it would not update the resolutions or either removing it in upgrade-interactive completely.

The first approach would be preferable since despite the version of a package is pinned, it should let the user know that this pinned package has some updates in it, which may mean that the reason for pinning it in the first place may be already fixed, making the user update it to the latest version instead of the pinned one.

[aalpgiray]

Also if you run update and select only packages under resolutions it is not doing any modification. Just prints package names to console. Is that the intended way?