docs: Add renovate related best practices guide

[Gabriel-Ladzaretti]

Changes

Nothing

Context

#15442

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/modified unit tests, or
• No unit tests but ran on a real repository, or
• Both unit tests + ran on a real repository

[Gabriel-Ladzaretti]

First draft 😀

[Gabriel-Ladzaretti]

if we do plan to have this, do we want to permit some renovate related prefix for API scheme checking
like in here:

renovate/lib/modules/versioning/index.spec.ts

Lines 110 to 113 in b87b3b0

	.filter(
	(val) => !optionalFunctions.includes(val) && !val.startsWith('_')
	)
	.sort();

and here:

renovate/lib/modules/versioning/index.spec.ts

Lines 140 to 144 in b87b3b0

	const schemeKeys = getAllPropertyNames(api)
	.filter(
	(val) => !optionalFunctions.includes(val) && !val.startsWith('_')
	)
	.sort();

as of now, underscore is used to indicate private class variables and methods (like _parse in genericVersioning) and the above

[viceice]

We should probably be relaxed here, as we otherwise can't easily distinguish between private and public api 🤔

[Gabriel-Ladzaretti]

so we leave the test as is.
should we keep this bullet point?

[HonkingGoose]

@Gabriel-Ladzaretti Why are you creating new commits, instead of applying my suggestions?

Renovate contributing guide, apply maintainer provided review suggestions.

[Gabriel-Ladzaretti]

@Gabriel-Ladzaretti Why are you creating new commits, instead of applying my suggestions?

Renovate contributing guide, apply maintainer provided review suggestions.

No specific reason, i just prefer working from the IDE.
If batch committing is the preferred way of doing things, ill follow that from now on np :D

[rarkins]

Yes please do, it's easier to track for the reviewer as well as gives appropriate credit for the changes through GitHub

[rarkins]

As a general rule, in this project we should always favor coding standards which can be enforced via linting. Are there any in this list which are already enforced, or which could be, e.g. via eslint? Are there any which we should use our own custom eslint plugin to enforce?

[viceice]

some small annotations

[viceice]

what is pure 🤔

[Gabriel-Ladzaretti]

should we add an explanation ? i.e

pure functions

• are predictable: given the same input, always returns the same output.
• have no side effect

[HonkingGoose]

Please add that explanation. 😉

[Gabriel-Ladzaretti]

I've added the explanation given in the provided wiki page.
hope its alright

[viceice]

otherwise LGTM

[renovate-release]

🎉 This PR is included in version 32.66.5 🎉

The release is available on:

• GitHub release
• 32.66.5

Your semantic-release bot 📦🚀