Formatters & Code
Dependabot Group Rule Tester — Preview Dependency Update Groups
Test and simulate GitHub Dependabot group rules locally. Preview pull request groupings, catch shadowed rules, verify update-types, and stop PR inbox floods.
Configuration & dependency updates
or click to browse from your computer (processed 100% locally)
Paste output from npm outdated, dotnet list package --outdated, or lines like express 4.18.2 -> 4.19.2 dev
Results
What the result means
This tool simulates how GitHub Dependabot evaluates and bundles dependency updates against your .github/dependabot.yml configuration file without needing a GitHub repository or API tokens. When Dependabot runs, it assigns each pending dependency update to the first matching group rule in sequential top-to-bottom order. If a broad catch-all group appears early, subsequent specific rules become dead code. Furthermore, group definitions default to applies-to: version-updates, which causes Dependabot to spawn separate individual pull requests for every security vulnerability alert unless a dedicated security-updates group is defined. The simulator parses your YAML, performs static health checks for rule shadowing and syntax traps, runs a deterministic matching engine across your dependency updates list, and renders a realistic preview of the generated pull requests and branch names alongside an interactive decision trace.
Related tools
Questions
Why did Dependabot ignore my groups and create over 100 separate pull requests?
The two most common causes are security update triggers and group order. First, groups default to "applies-to: version-updates". When security vulnerability (CVE) alerts trigger updates, Dependabot bypasses your groups and creates individual PRs unless you explicitly create a group with "applies-to: security-updates". Second, if an early group has broad patterns or dependencies, or if your packages have major version bumps while the group only allows minor/patch updates, those packages drop out of the group into individual pull requests.
How does Dependabot handle dependencies that match multiple group rules?
Dependabot assigns a dependency to the first group that matches in sequential order. Once a package matches an inclusion pattern and satisfies update-types and dependency-type filters, it is claimed by that group. It is never evaluated against subsequent groups. For this reason, specific package groups (such as "@angular*" or "eslint*") should always be defined above general groups (such as "dev-dependencies" or "*").
What is the syntax difference between ignore rules and group rules for update types?
In Dependabot "ignore" conditions, GitHub requires full string names like "version-update:semver-major" or "version-update:semver-minor". However, inside "groups" blocks, GitHub only accepts short strings: ["major", "minor", "patch"]. Copy-pasting the "version-update:semver-*" syntax into group rules causes Dependabot to fail or skip the group.