renovate grouped 12 unrelated major bumps into one PR - the agent's grouping pattern was too greedy

TL;DR: Your matchPackagePatterns matched everything, so renovate did exactly what you asked and grouped everything. Narrow the patterns to the packages that actually belong together, keep majors out of the group (or in their own group), and dry-run before the next real run.

renovate grouped 12 unrelated major bumps into one PR - the agent's grouping pattern was too greedy

Steps

1. Find the offending rule in your renovate config - look for a packageRule with a broad matcher like matchPackagePatterns: [".*"] combined with a groupName.

Expected: one rule matching far more packages than intended.

1. Replace the greedy pattern with explicit package names or a tight prefix, e.g. matchPackageNames: ["lodash", "underscore"] or a pattern scoped to your own org prefix.

Expected: the rule now names the family it is actually for.

1. Decide what majors do: add matchUpdateTypes: ["minor", "patch"] to the group so majors stay out, or give majors their own groupName.

Expected: majors arrive separately, where their breaking changes are reviewable.

1. Dry-run the config and inspect the planned PR list (renovate supports a dry-run mode; the hosted app also exposes debug logs per run).

Expected: the 12 packages split into sensible groups or individual PRs instead of one mega-PR.

1. Apply and watch the next run.

Expected: grouped PRs you can actually review, each with a coherent blast radius.

Use this when

• One renovate PR bundles unrelated packages together
• A grouping rule uses * or .* style match-everything patterns
• Major bumps got swept into a group with minors and patches
• CI fails on a grouped PR and nobody can tell which package caused it

Not for this skill when

• Renovate is not grouping at all (every bump separate) - that is a missing groupName problem, the opposite fix
• The grouping is dependabot's, not renovate's - different config, different fix
• The 12 bumps are genuinely related (one framework's ecosystem) - the grouping is correct, the PR is just big

Variant phrasings

• renovate packageRules grouped too many packages
• renovate one PR for all major updates - how to split
• matchPackagePatterns too broad renovate

Why it happens

Renovate's grouping is purely pattern-driven - it has no notion of "related" beyond what your matchers say. A match-everything pattern is a promise that every package belongs together, and renovate keeps that promise literally. Majors make it worse: twelve unrelated breaking changes in one PR means twelve suspects when CI goes red.

Edge cases

• matchPackagePatterns is regex, not glob - .* is the "match everything" footgun; scope it or replace it with matchPackageNames.
• Grouping interacts with scheduling: a group with mixed schedules waits for the slowest member - keep schedules consistent inside a group.
• Lock-file-only updates can sneak into groups - decide whether they belong or get their own rule.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst8jbNNE22yiFjp2qJ886Ig