Create config:best-practices preset

[HonkingGoose]

What would you like Renovate to be able to do?

We, as Renovate developers, want to have a way to tell our users: "here's what we recommend you do". A config:best-practice preset will help us do this.

Users can choose to extend from our config:best-practice preset. Nobody is "forced" into a workflow they may not like.

If you have any ideas on how this should be implemented, please tell us here.

Todo by Renovate programmer:

• Create new config:best-practices preset, which includes:
  • Pin GitHub Actions to SHA
  • Pin Docker digests
  • Pin all devDependencies
  • Any other important best-practice that the Renovate team recommends

Todo by @HonkingGoose:

• Explain the new config:best-practices preset in the new best practices upgrade file in PR docs: update best practices #22233
  • Explain why we created the config:best-practice(s) preset
  • Explain the reason behind each config option
  • How to use our presets (put it in your extends array)
  • Link to the preset config on the published docs

Related issues:

• Rename config:base -> config:recommended #12024
• Add helpers:pinGitHubActionDigests to config:base #11987

Is this a feature you are interested in implementing yourself?

Partially, I'll let somebody else do the code work, and I'll do the documentation work.

[PhilipAbed]

why did you choose
Pin GitHub Actions to SHA and Pin Docker digests
and how will any developer choose what best practices presets or configs to add ?
can you be more specific to what the config should be exactly?

[rarkins]

The idea is to add a new preset which is more "opinionated" than config:base. This should be based on the Renovate team's opinion on what people should be doing (e.g. pinning digests). It's not for individual developers to choose individually, it's for them to adopt if they agree in whole

[HonkingGoose]

Goal of the new preset

Make it easy for people to "do the right thing" by giving them a Renovate developer approved way to configure the bot. 😄

What other things to include?

@JamieMagee and @viceice Do you have any suggestions for other things that we should put in our new config:best-practices preset?

We also have some recommendations from Renovate docs, dependency pinning, So what's best. Do we want to include any of those into the preset?

So what's best?

We recommend:

1. Any apps (web or Node.js) that aren't require()'d by other packages should pin all types of dependencies for greatest reliability/predictability
2. Browser or dual browser/node.js libraries that are consumed/required()'d by others should keep using SemVer ranges for dependencies but can use pinned dependencies for devDependencies
3. Node.js-only libraries can consider pinning all dependencies, because application size/duplicate dependencies are not as much a concern in Node.js compared to the browser. Of course, don't do that if your library is a micro one likely to be consumed in disk-sensitive environments
4. Use a lock file

As noted earlier, when you pin dependencies then you will see an increase in the raw volume of dependency updates, compared to if you use ranges.
If/when this starts bothering you, add Renovate rules to reduce the volume, such as scheduling updates, grouping them, or automerging "safe" ones.

[rarkins]

Pinning all dev dependencies

[HonkingGoose]

It sounds like we have enough information to start working on this feature?

I'll need a developer to write the actual preset though. I'll be happy to work on the docs to highlight the new preset. 😉

[HonkingGoose]

@rarkins how about adding this issue to the v36 release list?

• v36 planning #21134

Now we're renaming config:base to config:recommended, I would be nice to also have the config:best-practice preset. Then we can highlight both config options in our major release note "blog". 😄

Having both presets allows users to:

• Ignore the presets, and cobble a working config together themselves
• Opt-in to our config:recommended preset, with reasonable defaults
• Opt-in to our config:best-practices preset, which extends from config:recommended and adds our best practices on top

[rarkins]

It's not breaking, but good idea to highlight it at the same time

[HonkingGoose]

@viceice can you add this issue to your v36 tracking issue?

• v36 planning #21134

[DuncanCasteleyn]

I'm willing to to open a pull request to add this preset.

I'm also wondering since this is a new preset why the link to v36, a new preset does not introduce a breaking change right? So a highlight in the v36 release might be wanted but should not stop adding it to v35 already?

[DuncanCasteleyn]

I have opened a draft pr to the main branch, I'll target v36 if required.
I have marked it as draft so @HonkingGoose can add the documentation changes and an another renovate dev can add more best practices that might still be missing here.

[HonkingGoose]

I'm also wondering since this is a new preset why the link to v36, a new preset does not introduce a breaking change right? So a highlight in the v36 release might be wanted but should not stop adding it to v35 already?

You're right, the new preset config:best-practice(s) is not a breaking change. But I think we still want to bundle it with v36.

My idea is to "launch" the config:best-practice(s) preset, with the v36 release. We're also intending to rename config:base to config:recommended in v36, I think.

config:base is not a neutral config, we put some "light" best practices into that preset. So calling it config:recommended makes it clear that it's more than just a basic preset.

Having both config:best-practice(s) and config:recommended in the same major release makes it easy for me to write our release blog, and explain why we're changing the names. 😄

[DuncanCasteleyn]

I'll target the v36 branch as soon as it exists 👍

[rarkins]

I guess we could merge it against v35 but then "announce" it as part of the v36 notes, which have a higher chance of being read than a regular feature release

[DuncanCasteleyn]

At that's left to do then is:

• Any other important best-practice that the Renovate team recommends
• Determine if the preset should be named config:best-practice or config:best-practices

The new page for the best practice preset can then be introduced in the new major version.

[HonkingGoose]

• Create new page in the docs, like docs/usage/best-practice-preset.md:

Do we still want a separate file just to explain the new preset? We could explain the new preset in the "Upgrade best practices" file that I'm already writing instead.

@rarkins can you pick from these options?

1. Put the config:best-practices preset explanation in the new docs: update best practices #22233 document, do not create new docs/usage/best-practice-preset.md file.
2. Create new docs/usage/best-practice-preset.md file to explain the new preset. Link to the preset docs in the upgrade best practices document.
3. Something else?

[rarkins]

(1)

[renovate-release]

🎉 This issue has been resolved in version 36.104.0 🎉

The release is available on:

• GitHub release
• 36.104.0

Your semantic-release bot 📦🚀