feat: replace deprecated dependencies with their replacements

[JamieMagee]

Changes:

Initial PR to add deprecated dependency replacement to Renovate.

This PR includes:

• A new update type, replacement
• A couple of new config options, replacementName and replacementVersion, designed to be used in packageRules
• A newName property in a few places, that's used in conjunction with the existing newVersion
• The start of a preset to track deprecated dependencies
• A small refactoring in the npm manager to extract twice repeated logic, instead of repeating it a third time See refactor(npm): extract replacement to a private function #11195

See JamieMagee/renovate-deprecation-replacements#8 for a sample PR

Context:

Closes #2223
Closes #5535
Closes #3339

Documentation (please check one with an [x])

• I have updated the documentation, or
• No documentation update is required

How I've tested my work (please tick one)

I have verified these changes via:

• Code inspection only, or
• Newly added unit tests, or
• No new tests but ran on a real repository, or
• Both unit tests + ran on a real repository

[JamieMagee]

@rarkins @viceice The implementation isn't ready for review yet, but I would appreciate your input on the design.

[viceice]

Shouldn't we do this in a more general way, so we can support all managers?

Moving the deprecation list to presets is fine for me. But how to manage them? Maybe we can do this as a comunity preset too, like for the docker image regex versioning? renovatebot/presets#44

[rarkins]

I'll just start by saying there's demons in these lands! I hit so many edge cases when I started this previously that I stopped, although our code has improved a lot since then.

Use cases:

• Package X got renamed to Y, and & started numbering at the same or earlier version that X got stopped at (change package name only, assuming X is up to date)
• Package X got renamed to Y, but Y started numbering after (needs to be both a rename and an upgrade)

Nice to support:

• "we want to replace all Docker Hub library images with our internal equivalent, e.g. node with mycompany/node. Easiest if we simply ignore versions/tags here, let it be their problem not our problem.. but it could cause problems if there isn't a match.

Logically, "renaming" feels similar to "pinning", in that it might exist independently of upgrade PRs that also co-exist. e.g. then updateType could be "replaceDep" for example.

@JamieMagee any particular "design decisions" you want to discuss?

[JamieMagee]

@viceice You mean something like not tying it to the deprecation message (currently only supported in npm and cargo), and instead just doing the check for deprecation somewhere like https://github.com/renovatebot/renovate/blob/master/lib/datasource/index.ts#L37-L39

The deprecation list would have to be manually managed, similar to how the group presets are done right now. Can you show me what you mean by the docker regex?

@rarkins Haha, yeah I've been trying to go through a lot of the backlog recently and fix a lot of issues that have been open for a long time. In my opinion this one could bring a lot of value.

The design decision I wanted to discuss were around how the renaming and version change would work. I think I can cover your 2 use cases (somewhat). My idea is that whenever we define a dependency replacement, we have to define the new package name, and new package version. The new package version should be the lowest stable version of the replacement package, in order to minimise the possibility of breaking changes. Subsequent runs of Renovate can then update the replacement package versions.

A psuedo-code version would look something like

{
'jade': {
  'name': 'pug',
  'version': '2.0.0'
},
...

I think this might also cover your 'nice-to-have' use case as well, although it's not the main priority.

[viceice]

@JamieMagee yes, we want to add some comunity presets with rules eg from renovatebot/config-help#529. so we can also add custom deprecation rules there too.

So we can deprecate packages for any datasource, if a rule forces this.

[rarkins]

@JamieMagee defining the minimum dependency you can switch to would be good. Renovate could apply logic like for vulnerability alerts currently where it deliberately picks the first satisfying version, i.e. the minimum risk.

BTW ideally:

• As few new config options added as possible
• Make it packageRule-able so that any "community" mappings could be moved into a community preset, consisting of essentially just regular packageRules, meanwhile people with their own custom rules (such as moving from a public Docker Hub image to their own custom ones) could also use very similar package rules

[JamieMagee]

So with the new changes, the rules are now packageRule-able. So for my example above it would be

"packageRules": {
  "packageNames": ["jade"],
  "replacementName": "pug",
  "replacementVersion": "2.0.0"
}

I think this is as generic as I can make it. Managers will still need to handle the actual replacement in updateDependency()

[viceice]

With new generic replacement it should work for all new managers an those ported to simple replacement.

[JamieMagee]

With new generic replacement it should work for all new managers an those ported to simple replacement.

Yeah, and we can backport the functionality to the other managers as required. I'm almost certain that npm will be ~50% of use cases though 😄

[ChristianMurphy]

With new generic replacement it should work for all new managers an those ported to simple replacement

This would be helpful for #5667

[JamieMagee]

Okay, so I think I have a dependency cycle somewhere 🤦

[viceice]

Needs coverage fixes.

[JamieMagee]

@rarkins Trying my best to get the number of PRs down 👍

Sample PR here.

Ready for further review (maybe even merge!)

[rarkins]

@JamieMagee Sorry, I need some time to think if this has unintended consequences for my plans for autoReplace and refactoring of updates in general. Let's not merge quite yet.

[JamieMagee]

@rarkins no worries. I'll move this back to draft for now.

[JamieMagee]

Squashed all the commits to make rebasing/merging with updated main easier in the future. Moving this PR to draft.

[viceice]

Otherwiese LGTM

[HonkingGoose]

I think this PR also resolves issue #3339?

[JamieMagee]

I think this PR also resolves issue #3339?

I agree. I've added it to the list of issues this PR closes.

[JamieMagee]

@rarkins there is still 1 unresolved comment, but I can't actually get to it from the GitHub UI 🤔

[HonkingGoose]

@rarkins there is still 1 unresolved comment, but I can't actually get to it from the GitHub UI 🤔

I think that's because the commit is gone from the branch, and GitHub can't find the correct place to display the unresolved comment.

[viceice]

@rarkins there is still 1 unresolved comment, but I can't actually get to it from the GitHub UI 🤔

I think that's because the commit is gone from the branch, and GitHub can't find the correct place to display the unresolved comment.

found and resolved, you need to check the hidden pr comments 😉

[JamieMagee]

@rarkins Looks like we're ready for merge with this 🤯

[renovate-release]

🎉 This PR is included in version 29.6.0 🎉

The release is available on:

• GitHub release
• 29.6.0

Your semantic-release bot 📦🚀

[voxpelli]

Is this something you would be able to consume from npm eventually? If people were to start providing this in their package.json when they are deprecating a package?

[rarkins]

@voxpelli in theory yes, but in practice I think that the volume of deprecations is reasonably low and so maintaining the list in presets is pretty manageable