Group by update level and dependency type, and keep major updates out of the group. A group of patch and minor updates for development tools is easy to review and revert. A group that mixes a major framework bump with nine patches hides the one change that needs attention.
What grouping options usually exist
The documentation for one widely used bot lists these group filters: dependency type (development or production, available for several package managers), name patterns with wildcards and exclusions, and update types (patch, minor or major). By default a group includes every update level. A dependency that matches more than one group lands in the first group that matches, and anything unmatched still gets its own pull request.
Those details matter. Order of group definitions changes results, and a missing filter means majors can slip in.
Good groups and bad groups
| Group | Verdict | Reason |
|---|---|---|
| Development dependencies, patch and minor | Good | Low blast radius, easy revert |
| Production dependencies, patch only | Good | Small changes, one review |
| One framework family by name pattern | Good | Pieces must move together |
| All dependencies, all update levels | Bad | Hides majors and 0.x minors |
| Production minor plus major | Bad | Mixes routine and breaking work |
Steps to set up grouping
- Count your last 30 bot pull requests by type: patch, minor, major, development, production.
- Create a group for development dependencies limited to patch and minor.
- Create a group for production patch updates only.
- Add name pattern groups for packages that must upgrade together, such as a framework and its plugins.
- Leave majors ungrouped so each gets its own pull request, title and owner.
- Exclude 0.x packages from broad groups, since the semantic versioning specification allows breaking changes at any time in major version zero.
The trade-offs
Larger groups mean fewer pull requests but harder diagnosis when CI fails. If a group of twelve fails, you must find which one broke. Smaller groups cost more review clicks but pinpoint failures. A decent starting size is a group you could bisect in a few minutes.
Grouping also changes your audit trail. One merge commit for twelve bumps means a revert undoes all twelve. Decide whether that is acceptable. For security fixes, many teams keep each pull request separate so a single advisory maps to a single change.
Check your results
After two weeks, look at how often a grouped pull request needed splitting. If you split more than occasionally, tighten the group. If you never touch the group beyond clicking merge, you may be able to widen it, within the limits above.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how findings are prioritized rather than listed one by one. Grouping should follow the same idea: review by risk, not by file.
Quick check
Should security fixes be grouped?
Often no. A separate pull request per advisory keeps the link between a vulnerability and its fix clear for audit and revert.
Does grouping reduce the number of CI runs?
Yes, because there are fewer branches. The cost is slower diagnosis when a group fails.
Safeguard scans manifests and lockfiles into an SBOM, uses reachability analysis to show which flagged dependencies your code actually calls, and can open fix pull requests (off by default, every category on Manual). You can try a free scan on a public repository.
Sources
Last reviewed: 19 October 2026.
