Dependency replacement can cause changelog, PR body errors

[rarkins]

How are you running Renovate?

WhiteSource Renovate hosted app on github.com

If you're self-hosting Renovate, tell us what version of Renovate you run.

No response

Please select which platform you are using if self-hosting.

No response

If you're self-hosting Renovate, tell us what version of the platform you run.

No response

Describe the bug

I noticed errors in the app logs which seem to be triggered by a replacement. Logs are below.

A different type of problem is evidence in the PR body:

(form8ion/react-components-scaffolder#622)

This seems to be happening as a result of this migration: https://github.com/form8ion/renovate-config/blob/8c027a47762940d66c6deb9400a74a1ff08c9ff8/js-replacements.json#L3-L8

I'm not sure the best way to address this, but wanted to raise a bug so it's on record.

Cc @travi @JamieMagee

Relevant debug logs

Logs

TypeError: Invalid Version: ^10.1.0 || ^11.0.0-alpha.1 || ^12.0.0 || ^13.0.0 || ^14.0.0 || ^2.0.0
at new SemVer (/home/ubuntu/renovateapp/node_modules/renovate/node_modules/semver/classes/semver.js:38:13)
at compare (/home/ubuntu/renovateapp/node_modules/renovate/node_modules/semver/functions/compare.js:3:32)
at Object.eq [as equals] (/home/ubuntu/renovateapp/node_modules/renovate/node_modules/semver/functions/eq.js:2:29)
at getChangeLogJSON (/home/ubuntu/renovateapp/node_modules/renovate/dist/workers/pr/changelog/index.js:18:21)
at embedChangelog (/home/ubuntu/renovateapp/node_modules/renovate/dist/workers/repository/changelog/index.js:9:62)
at /home/ubuntu/renovateapp/node_modules/p-map/index.js:57:28
at runMicrotasks (<anonymous>)
at processTicksAndRejections (internal/process/task_queues.js:95:5)

Have you created a minimal reproduction repository?

No reproduction, but I have linked to a public repo where it occurs

[travi]

it does seem like peer-dependencies are not handled very well at this point, but there are enough ways to handle that type of update that i wasn't surprised, especially remembering this comment from the initial implementation.

i found it odd that the normal additive approach was used rather than replacing the range definition since the dependency completely changed, but since i needed to make other manual adjustments, that wasn't a big deal. i decided that the previous range definition was overly restrictive, so i changed to use >=2.0.0 instead of ^2.0.0. also, since this was now a different peer requirement, i modified to release as a breaking change.

side note for additional context, you'll notice that i linked above to a commit that i did not make as an addition to the renovate PR before it was merged. i normally auto-merge everything as long as all checks pass (although i cannot take advantage of the new use of native auto-merge since i dont have branch protection for passing checks enabled in most of my projects). i was surprised after defining this replacement that this PR auto-merged since it didnt dawn on me until it happened that nothing would fail a check as a result of the peer dependency change. (it is a defined as a peer in the first place because these plugins don't directly rely the package in question, but instead expect to be used in that context). i disabled auto-merge for replacements as a result and because i can't really imagine a scenario where manual changes aren't needed before merging these PRs.

anyway, i understand that this issue is just for handling the errors, but thought some of that context might be helpful to understand the larger situation. even with the need for manual adjustments, this is a really useful feature for tracking down the usages that need to be migrated. also, thanks for keeping an eye on things and spotting details to improve :)