renovate/renovate
1
0
Fork 0
mirror of https://github.com/renovatebot/renovate.git synced 2025-01-11 22:46:27 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions 5
renovate/docs/development/creating-editing-renovate-presets.md
Michael Kriese f9e3e80e0c feat(presets)!: rename config:base to config:recommended (#21136) 
Closes #12024

Co-authored-by: Rhys Arkins <rhys@arkins.net>
Co-authored-by: HonkingGoose <34918129+HonkingGoose@users.noreply.github.com>
Co-authored-by: Bastian Gutschke <bastian.gutschke@gmx.de>

BREAKING CHANGE: Preset config:base is now called config:recommended
2023-07-04 19:21:52 +02:00

2.3 KiB
Raw Blame History

Creating/editing Renovate presets

Renovate comes with default presets that you can find in the lib/config/presets/internal directory. You can suggest changes to the presets with a pull request.

Follow the rules below to increase the chance that your pull request gets merged.

General rules

  1. Avoid creating presets for problems which can be fixed upstream
  2. The internal preset should be helpful for a significant number of Renovate users

Specific rules

Group presets

We have multiple kinds of group: presets, with different rules.

Rules for group:monorepo preset
  1. Only group dependencies that must be updated together
Rules for group:recommended presets
  1. The group:recommended preset is for related dependencies which aren't from a monorepo but which usually need to be updated together as separate PRs may each break
Rules for group:* presets
  1. Finally, any other group:* presets can be added if they are beneficial to a wide number of users
  2. They don't need to be added to group:recommended, meaning that users will "opt in" to them one by one and not get them automatically from config:recommended, which includes group:monorepo and group:recommended

Replacement presets

Rules:

  1. Replacement PRs should ideally propose a replacement only once the user is on a compatible version, by specifying a compatible matchCurrentVersion constraint
  2. If no compatible replacement upgrade is possible, it's acceptable to propose an incompatible one (e.g. a major version upgrade)
  3. 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

Monorepo presets

Rules:

  1. The primary use case of monorepo presets is finding packages from the same origin source repository which should be updated together
  2. Packages from the same repository which are developed and versioned independently do not need to be grouped as a monorepo, but in many cases we still do
  3. Packages from separate repositories but which are released together and dependent on each other may also be added to the "monorepo" definitions even if not strictly true