-
Notifications
You must be signed in to change notification settings - Fork 0
Expand file tree
/
Copy pathrenovate.json
More file actions
142 lines (142 loc) · 7.44 KB
/
Copy pathrenovate.json
File metadata and controls
142 lines (142 loc) · 7.44 KB
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
{
"$schema": "https://docs.renovatebot.com/renovate-schema.json",
"enabledManagers": ["github-actions", "npm", "cargo"],
"dependencyDashboard": true,
"timezone": "America/Los_Angeles",
"schedule": ["* * * * 1"],
"vulnerabilityAlerts": {
"description": [
"Security fixes must not wait for the Monday window. Everything else here is batched to one day a week, which is right for routine bumps and wrong for a known-vulnerable dependency, so this overrides the schedule only.",
"`minimumReleaseAge` is set here EXPLICITLY, and must stay that way. Renovate\u0027s own default for this block is `minimumReleaseAge: null`, force-applied before lookup — so omitting it does not inherit the cooldown from packageRules, it DROPS the cooldown entirely. Stating it is the only way to keep it.",
"Keeping it is the deliberate choice: the cooldown guards the opposite threat — a compromised release that gets yanked within a day — and a reviewer reading a Renovate diff cannot detect a supply-chain compromise the way the ecosystem\u0027s own yank process can. Nothing here auto-merges, and the Dependabot alert already makes the vulnerability visible the moment it is published, so what the cooldown costs is a day before the remediation PR appears, not a day before anyone knows.",
"See SECURITY.md, Dependency Supply Chain."
],
"enabled": true,
"schedule": [],
"minimumReleaseAge": "1 day",
"labels": ["security", "dependencies"]
},
"packageRules": [
{
"matchManagers": ["npm", "cargo"],
"rangeStrategy": "update-lockfile"
},
{
"matchManagers": ["github-actions"],
"groupName": "github-actions",
"groupSlug": "github-actions",
"separateMajorMinor": false
},
{
"description": "Require explicit approval for npm majors so framework migrations and runtime/tooling compatibility get a human review before a branch is created",
"matchManagers": ["npm"],
"matchUpdateTypes": ["major"],
"dependencyDashboardApproval": true
},
{
"description": "react and react-dom ship from one repo on one version number, and react-dom's client asserts an exact match against react at runtime — a split bump throws \"Incompatible React versions\" and fails the lib test suites. @types/react-dom peers on @types/react and both describe the runtime pair, so keep all four in one PR",
"matchManagers": ["npm"],
"matchPackageNames": [
"react",
"react-dom",
"@types/react",
"@types/react-dom"
],
"groupName": "react",
"groupSlug": "react",
"separateMajorMinor": false
},
{
"description": "React Router framework packages are peered and released together; do not split runtime and build tooling by dependency type",
"matchManagers": ["npm"],
"matchPackageNames": ["react-router", "@react-router/**"],
"groupName": "react-router",
"groupSlug": "react-router",
"separateMajorMinor": false
},
{
"description": "Tailwind core and first-party tooling should be tested together",
"matchManagers": ["npm"],
"matchPackageNames": ["tailwindcss", "@tailwindcss/**"],
"groupName": "tailwindcss",
"groupSlug": "tailwindcss",
"separateMajorMinor": false
},
{
"description": "Storybook core and its framework/addon packages are versioned in lockstep and their presets import across packages; a partial bump breaks the build, so keep them in one PR",
"matchManagers": ["npm"],
"matchPackageNames": ["storybook", "@storybook/**"],
"groupName": "storybook",
"groupSlug": "storybook",
"separateMajorMinor": false
},
{
"description": "Vitest runs on top of Vite and pins a peer Vite version; the Vite plugins are released against a Vite major. Bump them in one PR so a Vite/Vitest peer mismatch never lands split across incompatible versions",
"matchManagers": ["npm"],
"matchPackageNames": ["vite", "@vitejs/**", "vitest", "@vitest/**"],
"groupName": "vite",
"groupSlug": "vite",
"separateMajorMinor": false
},
{
"description": "xterm core and its first-party addons ship from one repo but carry INDEPENDENT beta counters (an addon is only published when its own content changes), and each addon peers on the exact core version published from the commit it was built from. So the latest of each is routinely a set spanning two commits — today's newest core has no matching addon publish at all — and since ^6.1.0-beta.N admits every later beta, npm and pnpm stay silent about the mismatch while the addons run against core internals they were not compiled for. This group only guarantees core and the addons arrive in one PR and are tested together; scripts/xterm-lint.mjs is what rejects an incoherent set, and `pnpm bump:xterm` writes the newest coherent one. Matched by scope so a newly added addon is grouped automatically; canopy's fork-base pins are excluded below",
"matchManagers": ["npm"],
"matchPackageNames": ["@xterm/**"],
"groupName": "xterm",
"groupSlug": "xterm",
"separateMajorMinor": false
},
{
"description": "@types/node must track the pinned Node runtime major and must not expose APIs newer than the runtime we bundle",
"matchManagers": ["npm"],
"matchPackageNames": ["@types/node"],
"allowedVersions": ">=24 <25"
},
{
"matchManagers": ["cargo"],
"groupName": "cargo",
"groupSlug": "cargo",
"separateMajorMinor": false
},
{
"matchManagers": ["npm", "cargo"],
"matchUpdateTypes": ["patch"],
"minimumReleaseAge": "1 day"
},
{
"matchManagers": ["npm", "cargo"],
"matchUpdateTypes": ["minor"],
"minimumReleaseAge": "3 days"
},
{
"matchManagers": ["npm", "cargo"],
"matchUpdateTypes": ["major"],
"minimumReleaseAge": "14 days"
},
{
"description": "Pin @types/vscode to match engines.vscode (^1.85.0) so the typed API surface never outruns the declared minimum VS Code runtime",
"matchManagers": ["npm"],
"matchPackageNames": ["@types/vscode"],
"allowedVersions": "1.85.0"
},
{
"description": "tend manages its own action version (the tend bot opens its own update PRs); don't let Renovate bump max-sixty/tend",
"matchManagers": ["github-actions"],
"matchPackageNames": ["max-sixty/tend"],
"enabled": false
},
{
"description": "Node version is governed by devEngines in package.json; don't let Renovate bump node in GitHub Actions workflows",
"matchManagers": ["github-actions"],
"matchPackageNames": ["node"],
"enabled": false
},
{
"description": "canopy pins the pristine @xterm/addon-webgl AND @xterm/xterm to the exact commit the SDF fork's sdf branch is based on (the addon's beta counter is offset from core's; canopy/README.md records the current correspondence). They are the UpstreamVsFork regression baseline and move in lockstep with the hand-cut @diffplug/xterm-addon-webgl-sdf tarball, which Renovate cannot see, so bumping either one is a manual edit made when the fork rebases — never a Renovate bump (see canopy/README.md and docs/specs/webgl-text.md). File-scoped: lib and standalone still track upstream betas via the xterm group above. Must stay last; later rules win",
"matchManagers": ["npm"],
"matchFileNames": ["canopy/package.json"],
"matchPackageNames": ["@xterm/**"],
"enabled": false
}
]
}