feat(replacements): fakerjs to scoped

[ST-DDT]

Changes

Created a replacement rule to replace the unmaintained faker with the community driven replacement @faker-js/faker

Context

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 select one)

I have verified these changes via:

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

[viceice]

why so many rules?

[Shinigami92]

why so many rules?

I don't really understand your question 🤔
Each rule serves different purposes. If someone is e.g. on v4, then switching the npm scope directly to v5.5.3 would result in breaking changes.
The new home kept the whole history and released backward-compatible legacy versions that were not changed.

[ST-DDT]

why so many rules?

I thought this was some kind of requirement:

renovate/docs/development/creating-editing-renovate-presets.md

Lines 36 to 38 in 15ac0b3

	1. Replacement PRs should ideally propose a replacement only once the user is on a compatible version, by specifying a compatible `matchCurrentVersion` constraint
	1. If no compatible replacement upgrade is possible, it's acceptable to propose an incompatible one (e.g. a major version upgrade)
	1. Replacements should update the user to the first recommended version of the new dependency and not include any new changes - whether breaking or not - if they can be avoided

Especially the specifying a compatible `matchCurrentVersion` constraint + not include any new changes - whether breaking or not part

And fastify does the same

renovate/lib/config/presets/internal/replacements.ts

Lines 229 to 240 in 2016c63

	matchCurrentVersion: '>=3.3.0 <4.0.0',
	matchDatasources: ['npm'],
	matchPackageNames: ['fastify-accepts-serializer'],
	replacementName: '@fastify/accepts-serializer',
	replacementVersion: '4.0.0',
	},
	{
	matchCurrentVersion: '>=2.3.0 <3.0.0',
	matchDatasources: ['npm'],
	matchPackageNames: ['fastify-accepts'],
	replacementName: '@fastify/accepts',
	replacementVersion: '3.0.0',

I can change them to all/only point to 5.5.3 if you want.

[Shinigami92]

I can change them to all/only point to 5.5.3 if you want.

I would suggest to NOT do that, because it violates:

Replacement PRs should ideally propose a replacement only once the user is on a compatible version, by specifying a compatible `matchCurrentVersion` constraint

[renovate-release]

🎉 This PR is included in version 37.183.0 🎉

The release is available on:

• GitHub release
• npm package (@latest dist-tag)
• 37.183.0

Your semantic-release bot 📦🚀