renovate: split testing tooling into vitest and playwright groups #124

Merged

ullrich merged 1 commit from renovate-split-testing-tooling into main 2026-09-07 12:27:25 +00:00

Conversation 0 Commits 1 Files changed 1 +58 -52

ullrich commented 2026-09-07 09:40:06 +00:00

Owner

Copy link

The testing tooling group sat before the matchUpdateTypes: ["major"], groupName: null rule. Later rules win in Renovate, so on a major the group name was discarded and the family re-split — precisely the bug the react-router rule already exists to fix, reproduced for test tooling.

It happened today

#121 (@vitest/browser v5) and #122 (@vitest/browser-playwright v5) opened as separate PRs and both were unmergeable on arrival:

// @vitest/browser@5.0.0 and @vitest/browser-playwright@5.0.0
"peerDependencies": { "vitest": "5.0.0" }

An exact pin, against a root manifest holding vitest: ^4.1.10. Neither PR could pass alone, and the pair could not pass together either — the set has to include vitest itself, which lives in a third manifest and was in neither PR.

The old comment argued a major "should be reviewed on its own." Sound in general; wrong for a set joined by an exact pin, where reviewing it alone means reviewing something that cannot merge.

Why two groups, not one moved group

The two families have no version relationship. @vitest/browser-playwright@5 peers playwright: "*". Playwright's real coupling is to the mcr.microsoft.com/playwright CI image — a separate axis. One combined group would tie two independent majors into a PR that lands only when both happen to be ready.

group	packages
vitest	vitest, @vitest/browser, @vitest/browser-playwright
playwright	playwright, playwright-core, @playwright/test, mcr.microsoft.com/playwright

Both now sit after the majors rule, alongside react-router, so each family stays intact on a major without dragging the other along. addLabels: ["major"] still applies — rules merge field-wise, so only groupName is overridden.

Verified

Parsed the file and read back the resolved order:

production (non-major) -> development -> docker base images -> <null>
  -> vitest -> playwright -> react-router

null-groupName rule at index 9, the two new rules at 10 and 11.

Also corrects the react-router comment, which cited "testing tooling above" as its counter-example. It is no longer above, and no longer a counter-example.

Follow-up

#121 and #122 should be closed once this lands. Renovate will reopen them as a single vitest group PR carrying all three packages — which is the only shape that can actually merge.

The `testing tooling` group sat **before** the `matchUpdateTypes: ["major"], groupName: null` rule. Later rules win in Renovate, so on a major the group name was discarded and the family re-split — precisely the bug the `react-router` rule already exists to fix, reproduced for test tooling. ### It happened today #121 (`@vitest/browser` v5) and #122 (`@vitest/browser-playwright` v5) opened as separate PRs and **both were unmergeable on arrival**: ```json // @vitest/browser@5.0.0 and @vitest/browser-playwright@5.0.0 "peerDependencies": { "vitest": "5.0.0" } ``` An exact pin, against a root manifest holding `vitest: ^4.1.10`. Neither PR could pass alone, and the pair could not pass together either — the set has to include `vitest` itself, which lives in a third manifest and was in neither PR. The old comment argued a major "should be reviewed on its own." Sound in general; wrong for a set joined by an exact pin, where reviewing it alone means reviewing something that cannot merge. ### Why two groups, not one moved group The two families have **no version relationship**. `@vitest/browser-playwright@5` peers `playwright: "*"`. Playwright's real coupling is to the `mcr.microsoft.com/playwright` CI image — a separate axis. One combined group would tie two independent majors into a PR that lands only when both happen to be ready. | group | packages | |---|---| | `vitest` | `vitest`, `@vitest/browser`, `@vitest/browser-playwright` | | `playwright` | `playwright`, `playwright-core`, `@playwright/test`, `mcr.microsoft.com/playwright` | Both now sit after the majors rule, alongside `react-router`, so each family stays intact on a major without dragging the other along. `addLabels: ["major"]` still applies — rules merge field-wise, so only `groupName` is overridden. ### Verified Parsed the file and read back the resolved order: ``` production (non-major) -> development -> docker base images -> <null> -> vitest -> playwright -> react-router ``` null-groupName rule at index 9, the two new rules at 10 and 11. Also corrects the `react-router` comment, which cited "testing tooling above" as its counter-example. It is no longer above, and no longer a counter-example. ### Follow-up #121 and #122 should be closed once this lands. Renovate will reopen them as a single `vitest` group PR carrying all three packages — which is the only shape that can actually merge.

ullrich added 1 commit 2026-09-07 09:40:08 +00:00

renovate: split testing tooling into vitest and playwright groups ... 433c5c7f32

The "testing tooling" group sat BEFORE the majors -> groupName: null rule. Later
rules win in Renovate, so a major lost the groupName and the family re-split —
precisely the bug the react-router rule exists to fix, reproduced for test
tooling.

It happened on 2026-09-07. #121 (@vitest/browser v5) and #122
(@vitest/browser-playwright v5) opened as separate PRs and BOTH were unmergeable
on arrival: @vitest/browser@5.0.0 and @vitest/browser-playwright@5.0.0 each
declare `peerDependencies: { vitest: "5.0.0" }`, an exact pin, while the root
manifest held vitest ^4.1.10. Neither could pass alone, and the pair could not
pass together either, because the set has to include `vitest` itself — which
lives in a third manifest and was never part of either PR.

The old comment argued a major "should be reviewed on its own". Sound in
general, wrong for a set joined by an exact pin: reviewing it alone means
reviewing something that cannot merge.

Splitting into TWO groups rather than moving one, because the two families have
no version relationship. @vitest/browser-playwright@5 peers `playwright: "*"`.
Playwright's coupling is to the mcr.microsoft.com/playwright CI image, a
separate axis entirely. One combined group would tie two independent majors into
a PR that lands only when both are ready.

Both are now placed after the majors rule, alongside react-router, so each family
stays intact on a major without dragging the other along. `addLabels: ["major"]`
still applies — rules merge field-wise, so only groupName is overridden.

Verified by parsing the file and reading the resolved order:
  production (non-major) -> development -> docker base images -> <null>
    -> vitest -> playwright -> react-router
with the null-groupName rule at index 9 and the two new rules at 10 and 11.

Also corrects the react-router comment, which pointed at "testing tooling above"
as the counter-example. It is no longer above, and no longer a counter-example.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01W9K6hHEZx5aqyWZKHNrxsD

ullrich merged commit d8faebe39c into main 2026-09-07 12:27:25 +00:00

ullrich deleted branch renovate-split-testing-tooling 2026-09-07 12:27:25 +00:00

ullrich referenced this pull request from a commit 2026-09-07 12:27:26 +00:00

Merge pull request 'renovate: split testing tooling into vitest and playwright groups' (#124) from renovate-split-testing-tooling into main

Sign in to join this conversation.

Reviewers

No reviewers

Labels

Clear labels   

dependencies

Dependency updates raised by Renovate (renovate.json5 labels)

  

major

Major version bump — always needs human review, never auto-merged

  

security-pin

Touches a pnpm.overrides CVE remediation pin, not an ordinary dependency

No labels

dependencies

major

security-pin

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

1 participant

Notifications

Subscribe

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference

trails-cool/trails!124

No description provided.