ci(renovate): group the browser/test tooling separately from development #60

Merged

ullrich merged 1 commit from ci/renovate-testing-group into main

2026-07-31 15:38:52 +00:00

ullrich commented

2026-07-31 15:37:08 +00:00

Owner

Carves the browser/test tooling out of the catch-all development group.

matchPackageNames: [
  "playwright", "playwright-core", "@playwright/test",
  "vitest", "@vitest/browser", "@vitest/browser-playwright",
],
groupName: "testing tooling",

Why these six, and not the three obvious ones

Two families, each with an exact internal pin, which is what forces them to move together:

@playwright/test           -> playwright-core   (exact)
@vitest/browser-playwright -> vitest            (exact: `vitest: 4.1.10`)

Let either family split across versions and pnpm installs two parallel trees that pnpm dedupe cannot merge — the exact pin makes the two lines incompatible by construction. Not hypothetical: #38 shipped playwright 1.62.0 and 1.62.1 side by side, dedupe left all four entries in place when run, and the fix was narrowing the manifest range.

The vitest side is the more fragile of the two, and it's why the group is wider than just the playwright trio: vitest is declared in the root while @vitest/browser* live in apps/planner, so there is no single file where the coupling is visible. The group is where it gets written down.

What this does not do

It does not prevent a split. These were already grouped under development when #38 happened — the divergence came from pnpm dedupe re-resolving after Renovate had picked versions, which no grouping can constrain.

What it buys is attributable failures. development currently bundles eslint, prettier, turbo, typescript-eslint, react-i18next, react-test-renderer and @types/node together with the test tooling. When that PR goes red you cannot tell which package caused it — #38 is the worked example. Splitting these out means an E2E or visual-regression failure points at the tooling that owns those suites.

Placement

After development so it wins under later-wins ordering, and before the majors -> groupName: null rule so a major is still reviewed on its own rather than being swept into the group.

Verified

Effective group computed per scenario, modelling matchManagers as well as matchDepTypes and matchUpdateTypes:

package	update	group
`playwright` / `@playwright/test` / `playwright-core`	minor, patch	testing tooling
`vitest` / `@vitest/browser` / `@vitest/browser-playwright`	minor, patch	testing tooling
`playwright`, `vitest`	major	(ungrouped)
`eslint`, `prettier`	minor, patch	development
`react-router` (catalog)	minor	production (non-major)
`node` (Dockerfile)	minor	docker base images

My first pass at that check omitted matchManagers and consequently reported everything as "docker base images" — worth mentioning because the corrected simulation is the only reason I can claim nothing else moved.

Carves the browser/test tooling out of the catch-all `development` group. ```json5 matchPackageNames: [ "playwright", "playwright-core", "@playwright/test", "vitest", "@vitest/browser", "@vitest/browser-playwright", ], groupName: "testing tooling", ``` ## Why these six, and not the three obvious ones Two families, each with an **exact** internal pin, which is what forces them to move together: ``` @playwright/test -> playwright-core (exact) @vitest/browser-playwright -> vitest (exact: `vitest: 4.1.10`) ``` Let either family split across versions and pnpm installs two parallel trees that **`pnpm dedupe` cannot merge** — the exact pin makes the two lines incompatible by construction. Not hypothetical: #38 shipped `playwright` 1.62.0 and 1.62.1 side by side, dedupe left all four entries in place when run, and the fix was narrowing the manifest range. The **vitest side is the more fragile of the two**, and it's why the group is wider than just the playwright trio: `vitest` is declared in the root while `@vitest/browser*` live in `apps/planner`, so there is no single file where the coupling is visible. The group is where it gets written down. ## What this does not do It does **not** prevent a split. These were already grouped under `development` when #38 happened — the divergence came from `pnpm dedupe` re-resolving *after* Renovate had picked versions, which no grouping can constrain. What it buys is **attributable failures**. `development` currently bundles eslint, prettier, turbo, typescript-eslint, react-i18next, react-test-renderer and `@types/node` together with the test tooling. When that PR goes red you cannot tell which package caused it — #38 is the worked example. Splitting these out means an E2E or visual-regression failure points at the tooling that owns those suites. ## Placement After `development` so it wins under later-wins ordering, and **before** the `majors -> groupName: null` rule so a major is still reviewed on its own rather than being swept into the group. ## Verified Effective group computed per scenario, modelling `matchManagers` as well as `matchDepTypes` and `matchUpdateTypes`: | package | update | group | |---|---|---| | `playwright` / `@playwright/test` / `playwright-core` | minor, patch | **testing tooling** | | `vitest` / `@vitest/browser` / `@vitest/browser-playwright` | minor, patch | **testing tooling** | | `playwright`, `vitest` | major | *(ungrouped)* | | `eslint`, `prettier` | minor, patch | development | | `react-router` (catalog) | minor | production (non-major) | | `node` (Dockerfile) | minor | docker base images | My first pass at that check omitted `matchManagers` and consequently reported *everything* as "docker base images" — worth mentioning because the corrected simulation is the only reason I can claim nothing else moved.

ullrich added 1 commit

2026-07-31 15:37:09 +00:00

ci(renovate): group the browser/test tooling separately from development

CI / Security Scan (pull_request) Successful in 2m34s

Details

CI / Dockerfile Package Check (pull_request) Successful in 52s

Details

CI / Checks (pull_request) Successful in 3m22s

Details

CI / Visual Tests (pull_request) Successful in 4m2s

Details

CI / Journal Image Smoke Test (pull_request) Successful in 40m50s

Details

CI / E2E Tests (pull_request) Successful in 11m13s

Details

9634cfdb81

Carves playwright and vitest out of the catch-all "development" group.

Two families, each with an EXACT internal pin, which is why they have to move
together:

  @playwright/test           -> playwright-core   (exact)
  @vitest/browser-playwright -> vitest            (exact: `vitest: 4.1.10`)

If either family splits across versions, pnpm installs two parallel trees that
`pnpm dedupe` cannot merge — the exact pin makes the lines incompatible by
construction. Not hypothetical: #38 shipped playwright 1.62.0 and 1.62.1 side by
side, dedupe left all four entries in place, and the fix was narrowing the
manifest range.

The vitest side is the more fragile of the two because it is split across
manifests — `vitest` in the root, `@vitest/browser*` in apps/planner — so there
is no single file where the coupling is visible. The group is where it gets
written down.

Being straight about what this does and does not do. It does NOT prevent a split:
these were already grouped under "development" when #38 happened, and the
divergence came from `pnpm dedupe` re-resolving after Renovate had picked
versions. What it buys is attributable failures. "development" bundles eslint,
prettier, turbo, typescript-eslint, react-i18next, react-test-renderer and
@types/node together with the test tooling; when that PR goes red you cannot tell
which package caused it — #38 is the worked example. Splitting these out means an
E2E or visual-regression failure points at the tooling that owns those suites.

Placed after "development" so it wins on later-wins ordering, and before the
majors -> groupName: null rule so a major is still reviewed on its own.

Verified by computing the effective group per scenario, modelling matchManagers
as well as depTypes and updateTypes (the first pass omitted matchManagers and
therefore reported everything as "docker base images"):

  playwright / @playwright/test / playwright-core   minor,patch -> testing tooling
  vitest / @vitest/browser / @vitest/browser-playwright         -> testing tooling
  playwright, vitest                               major       -> (ungrouped)
  eslint, prettier                                 minor,patch -> development
  react-router (catalog)                           minor       -> production (non-major)
  node (Dockerfile)                                minor       -> docker base images

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