Dependabot has no groups, so the pairs #282 consolidated by hand are split and red again

[Nicolas0315]

Summary

.github/dependabot.yaml has no groups, so every bump is opened as its own PR. For dependency families whose members must move together, that is not just noisy: whichever half opens first is red by construction, and neither can merge.

This is already documented. #282 consolidated 47 PRs by hand and its "Why one PR rather than 47" table lists five pairs that are "red on main as separate Dependabot PRs, and green here purely because they move together". The consolidation landed, but the config that produced the split did not change, so the same pairs are open and split again right now:

Pair from #282's table	Currently open as	Failing checks
vitest + @vitest/coverage-v8 -> 5.0.1	#290 / #291	4 / 2
vite 8 + @vitejs/plugin-react 6.1.1	#285 / #273	0 / 314
react + react-dom	#288 / #287	70 / 70
tailwindcss + @tailwindcss/vite 4.3.3	#277 / #270	1 / 0
codeql-action/init + /analyze	(merged via #282)	n/a

The coupling is structural, not incidental, and the manifests say so:

• @vitest/coverage-v8@5.0.1 declares peerDependencies of {"vitest": "5.0.1", "@vitest/browser": "5.0.1"}. An exact pin, not a range, so the split pair is unsatisfiable by construction regardless of what CI happens to catch.
• @vitejs/plugin-react@6.1.1 declares "vite": "^8.0.0". build(deps): bump @vitejs/plugin-react from 4.7.0 to 6.1.1 #273 is red across 314 checks on its own; it is only correct next to build(deps): bump vite from 6.4.2 to 8.3.0 #285.

#236 raising open-pull-requests-limit to 100 is what released the queue, and #282 describes the result as "47 full CI runs and, more importantly, wrong". With the limit raised and no grouping, that outcome is now the steady state rather than a one-off: the 2026-09-18 batch (#289 through #303) reproduced it within a week.

Proposal

Add groups to both ecosystem entries in .github/dependabot.yaml, one group per family, each with the evidence for its coupling in a comment beside it:

• npm: vitest (vitest, @vitest/coverage-v8), vite (vite, @vitejs/plugin-react), react (react, react-dom, @types/react, @types/react-dom), tailwind (tailwindcss, @tailwindcss/vite).
• github-actions: codeql-action (github/codeql-action*), since init and analyze are two entry points of one action repository and the runner rejects a mismatched pair.

Deliberately not grouped, because the manifests show no coupling: @vitest/eslint-plugin (versions independently, peers on vitest: "*"), the eslint plugin family (wide eslint ranges, no pins), oxlint + oxlint-tsgolint (oxlint-tsgolint declares peerDependencies: {}), drizzle-orm + drizzle-kit (drizzle-kit declares no peer on drizzle-orm). Grouping those would only hide which bump broke what.

This does not touch the three packages #282 held back (typescript 7.0.2, jsdom 30, eslint-plugin-unicorn 74); those are ignore/policy decisions, not grouping ones.

Notes

I have opened the equivalent change on the sibling repo as arkorlab/haru#46, where the codeql-action split was breaking every bump from 4.37.1 to 4.38.0 (ten in a row, 2026-07-17 to 2026-09-10, verified against the job logs at both ends of the range) and pinning the workflows to 4.37.0. The arkor side is the same root cause with a larger npm surface.

One caveat I could not settle from outside CI: whether Dependabot honours groups against catalog: entries in pnpm-workspace.yaml. Group matching is documented by dependency name and the pnpm-catalog support already resolves these names, so it should hold, but the first real proof is the next release of one of the paired packages. The github-actions group is unaffected, since actions are not catalog-resolved.

Happy to send the PR if the shape above looks right, or to adjust which families are in scope first.