Feature proposal: ignore lists for upgrade-interactive

[MeLlamoPablo]

What's the problem this PR addresses?

This PR adds the ability to ignore dependency upgrades on the yarn upgrade-interactive command.

This feature has been suggested or talked about in yarnpkg/yarn#3368 and yarnpkg/yarn#8005.

A developer may want to update package upgrades for many reasons, for example:

• A project might be locked in an old version and updating might not be feasible.
• An inconsequential patch might have been released (for instance, many maintainers choose to publish a new version when updating documentation or devDependencies).
• The new version could have incompatible license requirements. For example, husky v5 was relicensed to a non-OSI-approved license, which meant that proprietary projects were unable to upgrade.

Maintaining an ignore list has the advantage that it reduces clutter on the upgrade-interactive interface. Instead of each entry being simply informative of an outdated version, by empowering developers with the choice to ignore versions each entry behaves more like "a notification", which is more useful. For big teams another advantage is that it allows to document why a dependency was ignored, something that would otherwise be left out to issue trackers, Slack conversations, or more typically it would never be documented.

How did you fix it?

From the developer's perspective, they just continue using the same interface they know, except they can now press i to toggle between upgrading and ignoring a dependency:

yarn-upgrade-interactive-ignore-list-demo.mp4

The following lines are added to the developer's .yarnrc.yml automatically:

upgradeInteractiveIgnoredVersions:
  - "husky:^5.1.3"

Now, whenever the developer runs the same command again, husky won't appear anymore. More specifically, any versions that match ^5.1.3 will be ignored, which means that the next major version (e.g v6.0.0) will appear.

To ignore all future versions, they can change their configuration to:

upgradeInteractiveIgnoredVersions:
  - "husky:*"

Or to ignore that particular version, but be notified of new ones:

upgradeInteractiveIgnoredVersions:
  - "husky:5.1.3"

⚠️ Caveats

• This PR is made using 63a77b5 as the base, not master. This is because the upgrade to Clipanion 3 left this command broken (Migrates to Clipanion 3 #2370). This means that until master is fixed, this PR is not ready, hence why it's published as draft.
• This makes changes to @yarnpkg/core and @yarnpkg/libui which triggers releases in many pakcages. Because of this, I have not ran yarn version check. I would rather leave this up to maintainers.
• I make some opinionated design decisions, like the ignore list being stored in .yarnrc.yml, or increasing the complexity of the UI by adding an additional hotkey. I understand that these decisions might not be necessarily aligned with the project goals, so feel free to make any criticism, I'm open to any changes.

Checklist

• I have read the Contributing Guide.

• I have set the packages that need to be released for my changes to be effective.

• I will check that all automated PR checks pass before the PR gets reviewed.

[arcanis]

I'm not super fond of the API. It doesn't seem like something that should be configured via yet another field. Considering that semver already conveys whether something is compatible with higher versions or not (^x.y.z is open to new releases, x.y.z isn't), I feel like it should be enough. Perhaps we could just not show entries where the current range is exact, unless the user configured defaultSemverRangePrefix to an empty string?

[arcanis]

This PR is made using 63a77b5 as the base, not master. This is because the upgrade to Clipanion 3 left this command broken (#2370). This means that until master is fixed, this PR is not ready, hence why it's published as draft.

Master is fine (all our tests are passing), can you detail what doesn't work exactly?

[MeLlamoPablo]

Considering that semver already conveys whether something is compatible with higher versions or not (^x.y.z is open to new releases, x.y.z isn't), I feel like it should be enough. Perhaps we could just not show entries where the current range is exact, unless the user configured defaultSemverRangePrefix to an empty string?

That's a good point. It does make sense from my point of view. Personally I always use ^ because of force of habit. Before the era of lockfiles it made sense why someone would want to use an exact version instead of a range, but now it doesn't (to me).

However there are some concerns that come to mind:

1. What happens to developers who prefer using exact versions in package.json (but don't have defaultSemverRangePrefix configured)? They wouldn't see anything in the upgrade-interactive UI? Should we consider this a breaking change?
2. What happens to developers who have defaultSemverRangePrefix configured to an empty string? Are they unable to use this feature?
3. This is fine for the "I want to ignore a dependency forever" use case, but it removes the possibility to ignore a single version.

What do you think?

Master is fine (all our tests are passing), can you detail what doesn't work exactly?

Sorry man, I totally misunderstood your comment from #2370. I was testing with the current version of the yarn cli and Clipanion 3, no wonder it didn't work. I have updated this branch with master now.

[vinicius73]

Hi, any news about it?

[MeLlamoPablo]

Hi, any news about it?

@arcanis brought some good points about the complexity that this PR adds, but I don't think we will find an ideal solution that implements this feature without increasing complexity or adding breaking changes. However if we come to a solution I'm happy to put more work into this.

In the meantime a good alternative is adopting WhiteSource Renovate which supports ignoring specific versions. This is what I use with my employer and I personally don't have the need for this feature in yarn upgrade-interactive anymore.

[ssbarnea]

@arcanis What can we do make this happen? We have a bunch of dependencies that we do not want to update.

[rbnayax]

sorry to be that guy - but is there any news on this feature? cheers :-)