Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

docs: improve creating/editing Renovate presets #29331

Merged
merged 2 commits into from
May 30, 2024
Merged

docs: improve creating/editing Renovate presets #29331

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
9081f67
docs: improve creating/editing Renovate presets
HonkingGoose May 29, 2024
7d90713
Update docs/development/creating-editing-renovate-presets.md
HonkingGoose May 29, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
17 changes: 8 additions & 9 deletions docs/development/creating-editing-renovate-presets.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -8,7 +8,7 @@ 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
1. The internal preset should be helpful for a significant number of Renovate users
1. The internal preset should help a significant number of Renovate users

### Specific rules

Expand All @@ -22,24 +22,23 @@ We have multiple kinds of `group:` presets, with different rules.

##### 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
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
1. 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`
1. 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:
#### Rules for replacement presets

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
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, in short: pin the new version

#### Monorepo presets
If possible, replacement presets should give the user a replacement version that is _functionally identical_ to the _last version_ under the _old_ name.
We only want a user's tests to fail because of _broken references_ to the old package name, and not because the maintainer(s) changed the _behavior_ of the package.

Rules:
#### Rules for monorepo presets

1. The primary use case of monorepo presets is finding packages from the same origin source repository which should be updated together
1. 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
Expand Down