Shareable Config Presets

Renovate supports an eslint-like approach to shareable configs, which we usually refer to as “presets”. These are added/configured via the "extends" field in any configuration object.

Goals of Preset Configs

The main reason for supporting preset configs is to decrease duplication, both in terms of:

  1. You needing to duplicate common config across all of your repositories
  2. You needing to create/duplicate config that others have solved before

A secondary goal was to make Renovate configuration “self-documenting”, but adding the "description" field to all preset configs.

Implementation Approach

In order to achieve the above goals, preset configs have been implemented to allow a very modular approach - preset configs may be as small as a partial package rule or as extensive as an entire configuration, like an eslint config.

Example configs

An example of a small rule is “:preserveSemverRanges”, which has the description “Preserve (but continue to upgrade) any existing semver ranges” and simply sets the configuration option pinVersions to false.

An example of a full config is “:library”, which is Renovate’s default configuration for packages that are requiredd by other packages. In this case, it maintains semver ranges for dependencies but pins them for devDependencies, amongst other rules.

How to Use Preset Configs

By default, the Renovate onboarding process will suggest either the ":app" or ":library" preset configs. A typical onboarding renovate.json will therefore look like this:

{
  "extends": [":library"]
}

Let’s say you wish to modify that default behaviour, such as to schedule Renovate to process upgrades only during non-office hours. In that case you could modify the default renovate.json to be like this:

{
  "extends": [":library", "schedule:nonOfficeHours"]
}

This makes use of the schedules presets.

How to Publish Preset Configs

If you manage multiple repositories and want the same custom config across all or most of them, then you might want to consider publishing your own preset config so that you can “extend” it in every applicable repository.

Let’s say that your username on npm and elsewhere is “fastcore”. In that case, you can choose between publishing your preset config package as @fastcore/renovate-config or renovate-config-fastcore. Let’s assume you choose the latter.

You then need to publish the package containing a package.json with the field renovate-config and put your config under the field default. For example:

{
  "name": "renovate-config-fastcore",
  "version": "0.0.1",
  ...
  "renovate-config": {
    "default": {
      "extends": [":library", "schedule:nonOfficeHours"]  
    }
  }
}

Then in each of your repositories you can add your renovate config like:

  "extends": ["fastcore"]

Any repository including this config will then adopt the rules of the default library preset but schedule it on weeknights or weekends.