Shared Renovate presets for use in M365 projects.
- All configuration options
packageRules
configuration for applying custom options to individual packages or groups- Built-in presets (see also other pages in the same section)
- Preset definitions
There are a few different ways to reference presets from this repo in your Renovate config:
{
"extends": [
// Use the default preset
"github>microsoft/m365-renovate-config",
// Use a specific preset
"github>microsoft/m365-renovate-config:somePreset",
// Use a specific version of a preset
"github>microsoft/m365-renovate-config:somePreset#v2.1.0",
// Use a major version of a preset (see note below)
"github>microsoft/m365-renovate-config:somePreset#v2",
],
}
Note that semver ranges are not supported for preset versions because Renovate only supports resolving presets to specific refs (tags or branches). The supported refs are:
- Major version branches:
v1
,v2
- Tags listed on the Releases page
m365-renovate-config
version 2 makes the default preset a bit more opinionated based on testing, streamlines preset naming, and updates settings to better reflect recent improvements in Renovate.
These changes have been picked up automatically unless you specified a ref (e.g. #v1
) as part of the preset names in your extends
config.
Note: <m365>
in preset names referenced below is a shorthand for github>microsoft/m365-renovate-config
. This is just for readability of the readme and will not work in actual configs (you must use the full repo prefix).
The default preset (github>microsoft/m365-renovate-config
) is now a bit more "opinionated" and includes most settings that were previously defined in <m365>:libraryRecommended
. These settings can be disabled either individually or using the excludePresets
option.
The dependency version update strategy (rangeStrategy
) has also changed as described below.
Deprecated presets still exist for now to avoid immediate breaks in consuming repos, but will be removed in version 3.
<m365>:libraryRecommended
is deprecated in favor of this repo's default preset.<m365>:beachballLibraryRecommended
is renamed to<m365>:beachball
.
Previously, Renovate's config:base
(now config:recommended
) would pin devDependencies
and possibly also dependencies
to exact versions. Pinning dependencies
is usually not desirable for libraries, so v1
of m365-renovate-config
omitted any pinning behavior in its default preset, and enabled pinning only devDependencies
in its <m365>:libraryRecommended
preset.
A recent Renovate update included greatly expanded support for doing in-range updates (e.g. updating the installed version for "foo": "^1.0.0"
from 1.1.0
to 1.2.0
) by changing only the lockfile. Therefore, Renovate's default rangeStrategy: "auto"
was changed to do lockfile-only updates when possible (instead of pinning or replacing versions), and config:recommended
no longer includes any pinning of versions.
Since the lockfile-only updates are likely a good strategy in many cases, m365-renovate-config
's default preset (which supersedes <m365>:libraryRecommended
) has been updated to remove rangeStrategy
overrides and extend config:recommended
.
Notes on pinning behavior:
- For any versions that are currently pinned or that you manually pin, Renovate updates will bump to a new pinned version.
- If you'd like to unpin your dev deps, use
better-deps
:npx better-deps unpin-dev-deps
- If you'd like to unpin your dev deps, use
- If you prefer to restore the previous behavior of pinning all
devDependencies
, extend the Renovate preset:pinOnlyDevDependencies
.
- Full config presets
- Grouping presets
- Compatibility presets
- Freshness and noise reduction presets
- Other presets
Recommended config which is intended to be appropriate for most projects.
Show config JSON
{
"extends": [
"config:recommended",
"github>microsoft/m365-renovate-config:groupReact",
"github>microsoft/m365-renovate-config:newConfigWarningIssue",
"github>microsoft/m365-renovate-config:dependencyDashboardMajor"
],
"prConcurrentLimit": 10,
"prHourlyLimit": 2,
"printConfig": true,
"timezone": "America/Los_Angeles",
"vulnerabilityAlerts": {
"enabled": true
},
"packageRules": [
{
"matchDepTypes": ["devDependencies"],
"commitMessageTopic": "devDependency {{{depName}}}"
}
]
}
This preset extends Renovate's config:recommended
, which enables the following:
:ignoreModulesAndTests
: Ignore packages undernode_modules
or common test/fixture directory names:semanticPrefixFixDepsChoreOthers
: If the repo uses semantic commits, Renovate will usefix
for dependencies andchore
for othersgroup:monorepos
: Group known monoreposgroup:recommended
: Other known groupings (mostly not relevant for node)replacements:all
: Replace renamed packagesworkarounds:all
: Workarounds for known problems with packages
Extended presets from this repo:
groupReact
: Group React-related packages and typesnewConfigWarningIssue
: Create a new issue every time there's a config warning (not supported for Azure DevOps)dependencyDashboardMajor
: Require dependency dashboard approval for major upgrades (not supported for Azure DevOps)
Other settings:
- PR limits (
prHourlyLimit
andprConcurrentLimit
): Prevent Renovate from creating an overwhelming number of PRs all at once. It's highly encouraged to adjust these in your repo to fit your team's needs! printConfig
: Log the final resolved config to make debugging easiertimezone
: Run schedules relative to Pacific time, since many M365 repos are based in that time zone. See the time zone list for other options.vulnerabilityAlerts
: Enable PRs to address security vulnerabilities. Note that this only works for GitHub and currently is only able to update direct dependencies (except in repos usingnpm
6 or older).- For
devDependencies
: Use "devDependencies" in commit messages (instead of the default "dependencies") to be clearer about what is being modified
Recommended config for library repos which use Beachball for publishing.
Show config JSON
{
"extends": [
"github>microsoft/m365-renovate-config",
"github>microsoft/m365-renovate-config:beachballPostUpgrade"
]
}
This is a full config preset which extends the default preset and adds beachballPostUpgrade
to generate appropriate change files after upgrades:
- Change type
none
for updatingdevDependencies
- Change type
patch
for all other changes
These change types will be correct the majority of the time, but if a different change type is appropriate, you can always edit the change file in the PR before it merges.
Apply all the groupings from this repo (except groupTypes).
Show config JSON
{
"extends": [
"group:monorepos",
"group:recommended",
"github>microsoft/m365-renovate-config:groupD3",
"github>microsoft/m365-renovate-config:groupEslint",
"github>microsoft/m365-renovate-config:groupFixtureUpdates",
"github>microsoft/m365-renovate-config:groupFluent",
"github>microsoft/m365-renovate-config:groupJest",
"github>microsoft/m365-renovate-config:groupLageBackfill",
"github>microsoft/m365-renovate-config:groupNodeMajor",
"github>microsoft/m365-renovate-config:groupReact",
"github>microsoft/m365-renovate-config:groupRollup",
"github>microsoft/m365-renovate-config:groupYargs"
]
}
To use this preset but disable an individual grouping, add its name to the ignorePresets
array.
Group D3 updates.
Show config JSON
{
"packageRules": [
{
"groupName": "D3 packages",
"matchPackageNames": ["d3-*", "@types/d3-*"]
}
]
}
Group and schedule all eslint-related updates.
Show config JSON
{
"packageRules": [
{
"groupName": "eslint packages",
"matchPackageNames": ["/eslint/", "!@typecript-eslint/*"],
"schedule": ["before 5am on the 8th and 22nd day of the month"]
},
{
"groupName": "typescript-eslint monorepo",
"matchSourceUrls": ["https://github.com/typescript-eslint/typescript-eslint"],
"schedule": ["before 5am on the 8th and 22nd day of the month"]
}
]
}
Group, schedule, and auto-merge all dependency updates in __fixtures__
sub-folders.
Show config JSON
{
"ignorePresets": [":ignoreModulesAndTests"],
"ignorePaths": [
"**/node_modules/**",
"**/bower_components/**",
"**/vendor/**",
"**/examples/**",
"**/__tests__/**",
"**/test/**",
"**/tests/**"
],
"packageRules": [
{
"groupName": "fixture dependencies",
"schedule": ["before 5am on the 1st and 15th day of the month"],
"matchFileNames": ["**/__fixtures__/**"],
"matchPackageNames": ["*"],
"matchDepTypes": [
"dependencies",
"devDependencies",
"engines",
"optionalDependencies",
"overrides",
"packageManager",
"peerDependencies",
"resolutions"
],
"major": {
"dependencyDashboardApproval": false
},
"commitMessagePrefix": "[fixtures]",
"commitMessageExtra": "",
"automerge": true,
"platformAutomerge": true
}
]
}
The motivation for this is to reduce false positive Dependabot vulnerability alerts coming from test fixtures, since Dependabot has no way to ignore folders. The alerts are likely not meaningful for test fixtures, but dismissing them is extra work, and leaving them sitting creates noise and makes it harder to notice meaningful alerts.
This preset works by disabling Renovate's :ignoreModulesAndTests
preset, ignoring most of the same folders, and then creating a group encompassing all updates to all deps from package.json
files within the __fixtures__
folder.
Updates will occur once daily (to reduce noise) and will only be auto-merged if status checks pass. For updates only affecting fixtures, it should be safe to assume that if the tests using the fixture pass, it should be safe to auto-merge. However, in repos requiring a minimum number of reviews, the PR will still need to be manually reviewed.
Note that this will still make separate PRs for major and non-major updates unless separateMajorMinor
is set to false. (You can use a custom packageRules
entry with the same groupName
to do this.) Vulnerability update PRs may also be created separately and immediately.
To customize this rule's behavior for individual packages, you can add entries to packageRules
in your repo. For example:
- Exclude individual packages:
{ "groupName": "fixture dependencies", "matchPackageNames": ["!foo"] }
(or other exclusion options) - Limit the allowed versions for a specific package:
{ "matchPackageNames": ["foo"], "allowedVersions": "<6.0.0 }
Group Fluent UI and related package updates.
Show config JSON
{
"packageRules": [
{
"groupName": "Fluent UI React v9 packages",
"matchPackageNames": ["@fluentui/*"],
"matchCurrentVersion": ">=9.0.0-alpha.0"
},
{
"groupName": "Fluent UI React v9 packages",
"matchPackageNames": ["@griffel/*"]
},
{
"groupName": "Fluent UI React v8 packages",
"matchCurrentVersion": "/^[1234568]\\./",
"matchPackageNames": [
"@fluentui/*",
"!@fluentui/eslint-plugin",
"!@fluentui/react-conformance",
"!@fluentui/react-teams"
]
},
{
"groupName": "Fluent UI React v8 packages",
"matchPackageNames": ["@fluentui/react-cards"]
},
{
"groupName": "Fluent UI React Northstar packages",
"matchCurrentVersion": "0.x",
"matchPackageNames": [
"@fluentui/*",
"!@fluentui/eslint-plugin",
"!@fluentui/react-cards",
"!@fluentui/react-conformance",
"!@fluentui/public-docsite-setup"
]
},
{
"groupName": "Fabric packages",
"matchPackageNames": ["office-ui-fabric-react", "@uifabric/*"]
},
{
"groupName": "Fabric packages",
"matchPackageNames": ["@fluentui/react"],
"matchCurrentVersion": "^7.0.0"
}
]
}
This config creates the following groups:
Fluent UI React v8 packages
: Any packages corresponding to@fluentui/react
version 8Fluent UI React v9 packages
: Any packages corresponding to@fluentui/react-components
version 9Fluent UI React Northstar packages
: Any packages corresponding to@fluentui/react-northstar
Fabric packages
: Any packages corresponding tooffice-ui-fabric-react
or@fluentui/react
7 or earlier
If any packages are mis-categorized, please file an issue.
Group and schedule jest, ts-jest, jest types, and related packages.
Show config JSON
{
"ignorePresets": [
"monorepo:jest",
"group:jestMonorepo",
"group:jestPlusTypes",
"group:jestPlusTsJest"
],
"packageRules": [
{
"groupName": "Jest packages",
"matchSourceUrls": ["https://github.com/facebook/jest"],
"schedule": ["before 5am on the 8th and 22nd day of the month"]
},
{
"groupName": "Jest packages",
"matchPackageNames": ["@types/jest", "ts-jest", "@types/jest-*", "jest-*"],
"schedule": ["before 5am on the 8th and 22nd day of the month"]
}
]
}
This replaces the built-in presets group:jestMonorepo
, group:jestPlusTSJest
, and group:jestPlusTypes
with a group which catches more related dependencies.
Group Lage and Backfill packages (separate group for each).
Show config JSON
{
"packageRules": [
{
"groupName": "lage monorepo",
"matchSourceUrls": ["https://github.com/microsoft/lage"]
},
{
"groupName": "backfill monorepo",
"matchSourceUrls": ["https://github.com/microsoft/backfill"]
}
]
}
Group major updates of Node and its types.
Show config JSON
{
"packageRules": [
{
"groupName": "Node",
"matchPackageNames": ["@types/node", "node", "nodejs/node"],
"matchUpdateTypes": ["major"]
}
]
}
This preset should work for the Node version as defined by @types/node
dependency, engines.node
in package.json
, .nvmrc
, or .node-version
.
It does NOT work for actions/setup-node
(GitHub workflows) or NodeTool
(Azure Pipelines). For a workaround for GitHub workflows, see the notes on restrictNode
.
Group React packages and types.
Show config JSON
{
"packageRules": [
{
"groupName": "react monorepo",
"matchPackageNames": [
"@types/react",
"@types/react-dom",
"@types/react-test-renderer",
"@types/react-is",
"@types/scheduler"
]
}
]
}
This uses the same name as (and therefore extends) the built-in config group:reactMonorepo
.
Group all Rollup-related updates.
Show config JSON
{
"packageRules": [
{
"groupName": "rollup packages",
"matchPackageNames": ["/^@?rollup/"]
}
]
}
Group minor and patch updates to @types
devDependencies
.
Show config JSON
{
"packageRules": [
{
"groupName": "@types devDependencies",
"schedule": ["before 5am on the 1st and 15th day of the month"],
"matchManagers": ["npm"],
"matchDepTypes": ["devDependencies"],
"matchUpdateTypes": ["minor", "patch"],
"matchCurrentVersion": ">1.0.0",
"matchPackageNames": [
"@types/*",
"!@types/d3-*",
"!@types/jest-*",
"!@types/jest",
"!@types/react",
"!@types/react-dom",
"!@types/react-is",
"!@types/react-test-renderer",
"!@types/scheduler",
"!@types/yargs",
"!@types/yargs-parser"
]
},
{
"groupName": "@types devDependencies",
"matchManagers": ["npm"],
"matchPackageNames": ["@types/*"],
"matchDepTypes": ["devDependencies"],
"matchUpdateTypes": ["patch"],
"matchCurrentVersion": "0.x"
}
]
}
@types
packages can update frequently, and used as devDependencies
, they're generally low risk/effort to update. So this preset groups them together to reduce noise. It also uses an early-morning schedule since updates to @types
packages may be released throughout the day, and probably at most one PR per day is desired.
This group excludes updates to @types
packages with 0.x
versions since those could technically be breaking changes (and to avoid conflicting with the dependencyDashboardMajor
preset's 0.x
rule). It also excludes things such as @types/react
which are often included with other groups.
If you want to exclude a package from this group, add a new packageRules
entry as follows:
{
"groupName": "@types devDependencies",
"matchPackageNames": ["!@types/some-package"]
}
Group yargs, yargs-parser, and their types.
Show config JSON
{
"packageRules": [
{
"groupName": "yargs packages",
"matchPackageNames": ["yargs", "yargs-parser", "@types/yargs", "@types/yargs-parser"]
}
]
}
Note that if you depend on both yargs
and yargs-parser
, and they have different major versions, this preset can cause an immortal PR (so you may want to the ignorePresets
array).
Disable upgrades to package versions that have been converted to ES modules.
Show config JSON
{
"packageRules": [
{
"matchPackageNames": ["p-limit"],
"allowedVersions": "<4.0.0"
},
{
"matchPackageNames": ["chalk"],
"allowedVersions": "<5.0.0"
},
{
"matchPackageNames": ["ansi-regex", "execa", "find-up", "pretty-bytes"],
"allowedVersions": "<6.0.0"
},
{
"matchPackageNames": ["strip-ansi"],
"allowedVersions": "<7.0.0"
},
{
"matchPackageNames": ["supports-color"],
"allowedVersions": "<9.0.0"
},
{
"matchPackageNames": ["globby"],
"allowedVersions": "<12.0.0"
}
]
}
While ES modules are the new standard, migrating immediately may not be practical, in particular for libraries whose main consumers can't immediately migrate. This preset is a stopgap to prevent having to verify that every major update does not include an ESM conversion.
Restrict Node version to the range arg0
and ignore updates incompatible with your repo's engines.node
.
Show config JSON
{
"packageRules": [
{
"matchPackageNames": ["@types/node", "node", "nodejs/node"],
"allowedVersions": "{{arg0}}"
},
{
"matchManagers": ["npm"],
"constraintsFiltering": "strict"
}
]
}
This preset should work for the Node version as defined by @types/node
dependency, engines.node
in package.json
, .nvmrc
, or .node-version
.
It does NOT work for actions/setup-node
(GitHub workflows) or NodeTool
(Azure Pipelines). To ensure the Node version stays in sync for GitHub actions, it's recommended to either:
- Specify
engines.node
inpackage.json
and specifynode-version-file: package.json
in the action, or - Create a
.nvmrc
file and specifynode-version-file: .nvmrc
in the action
The preset also enables constraintsFiltering: "strict"
to prevent installing deps that are incompatible with your repo's engines.node
setting.
Keep locally-used dependency versions updated and deduplicated.
Show config JSON
{
"lockFileMaintenance": {
"enabled": true,
"rebaseWhen": "behind-base-branch",
"schedule": ["before 5am on the 1st and 15th day of the month"]
},
"postUpdateOptions": ["yarnDedupeFewer", "npmDedupe"],
"packageRules": [
{
"matchManagers": ["npm"],
"rangeStrategy": "replace"
}
]
}
lockFileMaintenance
: Completely re-create lock files twice a month. This will update direct and indirect dependency versions used only within the repo to the latest versions that satisfy semver.rebaseWhen
: If the lock file maintenance PR gets out of date, rebase it even if there aren't conflicts.
postUpdateOptions
:yarnDedupeFewer
: If using yarn, runyarn-deduplicate --strategy fewer
after updates.npmDedupe
: If using npm, runnpm dedupe
after updates. WARNING: This may slow down Renovate runs significantly.
Extend<m365>:minorDependencyUpdates
and set therangeStrategy
fornpm
devDependencies
toreplace
(see below for details).minorDependencyUpdates
was removed from the default config due to causing problematic duplication for consumer.rangeStrategy: "replace"
is now set for allnpm
dependencies.
With dependencies
and/or devDependencies
specified as ranges (unpinned), by default Renovate will make individual lockfile-only update PRs for in-range updates. These PRs are redundant when lockFileMaintenance
is also enabled, so setting rangeStrategy
to replace
will reduce unnecessary PRs.
(To unpin your devDependencies
that Renovate previously pinned, run npx better-deps unpin-dev-deps
.)
It's highly recommended to manually run the deduplication command (npx yarn-deduplicate --strategy fewer
or npm dedupe
) before enabling this preset. In a large repo that hasn't been regularly deduplicated or had its lock file refreshed, it's likely that initial deduplication will cause build breaks due to implicit reliance on subtle interactions between particular old versions.
For dependencies, explicitly pick up minor updates, and ignore patch updates if in-range.
Show config JSON
{
"packageRules": [
{
"matchManagers": ["npm"],
"matchDepTypes": ["dependencies"],
"rangeStrategy": "bump"
},
{
"matchManagers": ["npm"],
"matchDepTypes": ["dependencies"],
"matchCurrentValue": "/^[~^][1-9]/",
"matchUpdateTypes": ["minor"],
"schedule": ["before 5am on Tuesday"]
},
{
"matchManagers": ["npm"],
"matchDepTypes": ["dependencies"],
"matchCurrentVersion": "0.x",
"matchUpdateTypes": ["patch"],
"schedule": ["before 5am on Tuesday"]
},
{
"matchManagers": ["npm"],
"matchDepTypes": ["dependencies"],
"matchCurrentValue": "/^[~^][1-9]/",
"matchUpdateTypes": ["patch"],
"enabled": false
}
]
}
This preset is mainly useful if lockFileMaintenance
is enabled and some or all dependencies are specified as ranges. Note that it only applies to npm
dependencies
.
- For all
npm
dependencies
, set therangeStrategy
tobump
: bump the range even if the new version satisfies the existing range, e.g.^1.0.0 -> ^1.1.0
. - For
^
or~
dependencies
:- For versions >
0.x
, explicitly pick up minor updates once a week in case of API changes, and disable explicit patch updates. - For
0.x
versions, explicitly pick up patch updates once a week in case of API changes.
- For versions >
Update "noisy" (frequently-updating) packages once every other week.
Show config JSON
{
"packageRules": [
{
"matchPackageNames": ["@microsoft/api-extractor*"],
"schedule": ["before 5am on the 8th and 22nd day of the month"]
}
]
}
Certain packages tend to publish updates multiple times per week, and getting a PR for every one of those updates can be annoying. This rule includes a list of packages known to update frequently and spreads them out throughout the week (to avoid attempting to create too many PRs at once and being rate limited).
Auto-merge minor and patch updates to devDependencies
and lock file maintenance (if the build passes).
Show config JSON
{
"lockFileMaintenance": {
"automerge": true,
"platformAutomerge": true
},
"packageRules": [
{
"matchDepTypes": ["devDependencies"],
"matchUpdateTypes": ["minor", "patch"],
"automerge": true,
"platformAutomerge": true,
"internalChecksFilter": "strict",
"matchPackageNames": ["!typescript"],
"minimumReleaseAge": "2 days"
}
]
}
Any branch policies will be respected, including required status checks and required reviewers. If you have a required reviewers policy, this will prevent the PRs from merging in an entirely automated manner.
Experimentally, this preset has stabilityDays
set to 2 to reduce the chance of automerging malicious dependencies. You can force creation of the PR earlier using the dependency dashboard.
Auto-merge minor and patch updates to @types
devDependencies
(if the build passes).
Show config JSON
{
"packageRules": [
{
"matchPackageNames": ["@types/*", "!@types/react", "!@types/react-dom"],
"matchManagers": ["npm"],
"matchDepTypes": ["devDependencies"],
"matchUpdateTypes": ["minor", "patch"],
"automerge": true,
"platformAutomerge": true
}
]
}
Any branch policies will be respected, including required status checks and required reviewers. If you have a required reviewers policy, this will prevent the PRs from merging in an entirely automated manner.
Run beachball change
as a post-upgrade task.
Show config JSON
{
"gitAuthor": "Renovate Bot <[email protected]>",
"postUpgradeTasks": {
"commands": [
"git add --all",
"npx beachball change --no-fetch --no-commit --type patch --message '{{{commitMessage}}}'",
"git reset"
],
"fileFilters": ["**/*"],
"executionMode": "branch"
},
"lockFileMaintenance": {
"postUpgradeTasks": {
"commands": [
"git add --all",
"npx beachball change --no-fetch --no-commit --type none --message '{{{commitMessage}}}'",
"git reset"
],
"fileFilters": ["**/*"],
"executionMode": "branch"
}
},
"packageRules": [
{
"matchManagers": ["npm"],
"matchDepTypes": ["devDependencies"],
"postUpgradeTasks": {
"commands": [
"git add --all",
"npx beachball change --no-fetch --no-commit --type none --message '{{{commitMessage}}}'",
"git reset"
],
"fileFilters": ["**/*"],
"executionMode": "branch"
}
}
]
}
Generate appropriate change files after upgrades:
- Change type
none
for updatingdevDependencies
orlockFileMaintenance
- Change type
patch
for all other changes
These change types will be correct the majority of the time, but if a different change type is appropriate, you can always edit the change file in the PR before it merges.
Note that in the GitHub app, commands in postUpgradeTasks
are limited to a specific set of strings for security reasons. As of writing, only the specific commands used in this config are allowed (though --no-fetch
can optionally be removed).
Require dependency dashboard approval for major upgrades, 0.x upgrades, and minor upgrades of deps known not to follow semver.
Show config JSON
{
"dependencyDashboard": true,
"major": {
"dependencyDashboardApproval": true
},
"packageRules": [
{
"matchPackageNames": ["go", "typescript"],
"matchUpdateTypes": ["minor"],
"dependencyDashboardApproval": true
},
{
"matchCurrentVersion": ">=0.1.0 <1.0.0-0",
"matchUpdateTypes": ["minor"],
"dependencyDashboardApproval": true
}
]
}
Note: The dependency dashboard feature doesn't work in Azure DevOps as of writing due to lack of issue creation support in Renovate (and lack of markdown checkbox support in Azure DevOps).
Major upgrades of certain dependencies may be disruptive or require extra validation, so to avoid the PRs sitting for a long time, it may be desirable to manually approve upgrades.
This policy is also applied for certain minor upgrades that may contain breaking changes:
- Packages with
0.x
versions (allowed per semver) - Packages that don't respect major/minor semver: so far,
typescript
andgo
The downside of setting this policy for all major upgrades is that it reduces the visibility of available upgrades, if nobody is checking the dashboard regularly.
Some alternative strategies which would need to be configured per repo (see Renovate docs for examples):
- Create a
packageRules
group which requires dependency dashboard approval for only major upgrades of specific packages that are known to be high risk/effort. - Set schedules for individual
packageRules
groups to avoid the upgrades being forgotten.
Always create a new issue if there's a config problem (for visibility).
Show config JSON
{
"configWarningReuseIssue": false
}
Note that issue creation is not supported in Azure DevOps as of writing.
This project welcomes contributions and suggestions. Most contributions require you to agree to a Contributor License Agreement (CLA) declaring that you have the right to, and actually do, grant us the rights to use your contribution. For details, visit https://cla.opensource.microsoft.com.
When you submit a pull request, a CLA bot will automatically determine whether you need to provide a CLA and decorate the PR appropriately (e.g., status check, comment). Simply follow the instructions provided by the bot. You will only need to do this once across all repos using our CLA.
This project has adopted the Microsoft Open Source Code of Conduct. For more information see the Code of Conduct FAQ or contact [email protected] with any additional questions or comments.