rbrooks/Quest-Board

Watch

Fork 0

chore(deps): unblock @vitejs/plugin-react 6.1.1 with a peer override (#316) #471

Merged

claude-bot merged 1 commit from fix/316-plugin-react-6.1.1 into main

2026-08-31 20:10:52 +00:00

claude-bot commented

2026-08-31 20:01:06 +00:00

Collaborator

Supersedes #316, which cannot go green on its own.

Why #316 was stuck

It failed identically across six runs — 7173, 7320, 7417, 7502, 7581, 7719 — and would have kept failing on any number of retries. It is not the runner-disk problem that was failing #467/#468/#469 (those were OSError: [Errno 28] No space left on device; all three have since rebased, gone green and automerged).

That branch carried package.json at 6.1.1 and package-lock.json still at 6.0.5. The renovate/artifacts failure on the PR is the cause, not a symptom: Renovate could not regenerate the lockfile, so it pushed the manifest bump with a stale lock and CI could not install. Renovate rebased it again after the disk fix — the branch is now one line off main — and renovate/artifacts failed again, which rules staleness out as a variable.

The actual conflict

@vitejs/plugin-react@6.1.1 declares @rolldown/plugin-babel as an optional peer. Its own optional peer @babel/plugin-transform-runtime resolves to 8.0.1, which peers on @babel/core@^8. The tree has 7.29.7:

npm error Found: @vitejs/plugin-react@6.0.5
npm error Conflicting peer dependency: @babel/core@8.0.1
npm error   peer @babel/core@"^8.0.0" from @babel/plugin-transform-runtime@8.0.1
npm error     peerOptional @babel/plugin-transform-runtime@"^7.29.0 || ^8.0.0-rc.1" from @rolldown/plugin-babel@0.2.3
npm error       peerOptional @rolldown/plugin-babel@"^0.1.7 || ^0.2.0" from @vitejs/plugin-react@6.1.1

npm chases that chain during incremental resolution and gives up — even though it installs none of those packages. The overrides entry keeps that speculative resolution on the 7.x line, and the update goes through.

Two alternatives, both tested and rejected

Wait for lockFileMaintenance to refresh the lock first — does not work. I recommended this before testing it, and it is wrong. After a clean from-scratch regen at 6.0.5, the incremental bump to 6.1.1 hits the identical ERESOLVE. The conflict is not stale transitive versions; it is npm declining to re-plan around a pinned package.

Full from-scratch regen with 6.1.1 — works, but too wide. It rewrites 61 transitive versions (0 added, 0 removed — all @rollup/* and @rolldown/* platform-binding drift, @csstools/*, and similar). That is lockFileMaintenance's job, which renovate.json already schedules, not a single-dependency PR's.

What this PR does instead

The whole lockfile diff:

-        "@vitejs/plugin-react": "6.0.5",
+        "@vitejs/plugin-react": "6.1.1",
...
     "node_modules/@vitejs/plugin-react": {
-      "version": "6.0.5",
+      "version": "6.1.1",
       "peerDependencies": {
+        "oxc-transform-react": "^0.145.0",

The plugin's version, its integrity hash, and its own peer metadata — 6.1.1 adds oxc-transform-react as a new optional peer, part of its experimental native React Compiler support. @babel/core stays at 7.29.7.

A note on npm versions: regenerated with npm 11, matching whatever wrote the current lock. npm 10.9.8, which node:22 ships, silently drops the 32 "libc" entries and turns a 12-line diff into a 108-line one. CI consumes it with 10.9.8 either way.

Verification

Run with CI's own toolchain (node 22 / npm 10.9.8), not just a convenient one:

npm ci — clean
npm run lint — 0 errors (the single react-hooks/exhaustive-deps warning is pre-existing on main)
npm test — 43 files, 465 tests passed
npm run build — succeeds
audit gate (npm audit --omit=dev + audit-allowlist.mjs) — clean
docker build --target frontend-prod — succeeds (that job also failed on #316)

Follow-up

The override constrains a package that is not in the tree, so it needs to be removed when the frontend moves to Babel 8 — at that point it would hold @babel/plugin-transform-runtime back rather than unblock anything. JSON has no comments, so that is recorded under "Important constraints" in webapp/CLAUDE.md.

Worth expecting: with the override in place, Renovate's artifact step should succeed on future @vitejs/plugin-react bumps instead of failing this same way again.

🤖 Generated with Claude Code

Supersedes #316, which cannot go green on its own. ## Why #316 was stuck It failed identically across six runs — 7173, 7320, 7417, 7502, 7581, 7719 — and would have kept failing on any number of retries. It is **not** the runner-disk problem that was failing #467/#468/#469 (those were `OSError: [Errno 28] No space left on device`; all three have since rebased, gone green and automerged). That branch carried `package.json` at `6.1.1` and `package-lock.json` still at `6.0.5`. The `renovate/artifacts` failure on the PR is the *cause*, not a symptom: Renovate could not regenerate the lockfile, so it pushed the manifest bump with a stale lock and CI could not install. Renovate rebased it again after the disk fix — the branch is now one line off `main` — and `renovate/artifacts` failed again, which rules staleness out as a variable. ## The actual conflict `@vitejs/plugin-react@6.1.1` declares `@rolldown/plugin-babel` as an **optional** peer. Its own optional peer `@babel/plugin-transform-runtime` resolves to `8.0.1`, which peers on `@babel/core@^8`. The tree has `7.29.7`: ``` npm error Found: @vitejs/plugin-react@6.0.5 npm error Conflicting peer dependency: @babel/core@8.0.1 npm error peer @babel/core@"^8.0.0" from @babel/plugin-transform-runtime@8.0.1 npm error peerOptional @babel/plugin-transform-runtime@"^7.29.0 || ^8.0.0-rc.1" from @rolldown/plugin-babel@0.2.3 npm error peerOptional @rolldown/plugin-babel@"^0.1.7 || ^0.2.0" from @vitejs/plugin-react@6.1.1 ``` npm chases that chain during incremental resolution and gives up — **even though it installs none of those packages**. The `overrides` entry keeps that speculative resolution on the 7.x line, and the update goes through. ## Two alternatives, both tested and rejected **Wait for `lockFileMaintenance` to refresh the lock first — does not work.** I recommended this before testing it, and it is wrong. After a clean from-scratch regen at `6.0.5`, the incremental bump to `6.1.1` hits the identical ERESOLVE. The conflict is not stale transitive versions; it is npm declining to re-plan around a pinned package. **Full from-scratch regen with 6.1.1 — works, but too wide.** It rewrites **61** transitive versions (0 added, 0 removed — all `@rollup/*` and `@rolldown/*` platform-binding drift, `@csstools/*`, and similar). That is `lockFileMaintenance`'s job, which `renovate.json` already schedules, not a single-dependency PR's. ## What this PR does instead The whole lockfile diff: ``` - "@vitejs/plugin-react": "6.0.5", + "@vitejs/plugin-react": "6.1.1", ... "node_modules/@vitejs/plugin-react": { - "version": "6.0.5", + "version": "6.1.1", "peerDependencies": { + "oxc-transform-react": "^0.145.0", ``` The plugin's version, its integrity hash, and its own peer metadata — 6.1.1 adds `oxc-transform-react` as a new optional peer, part of its experimental native React Compiler support. `@babel/core` stays at `7.29.7`. **A note on npm versions:** regenerated with npm 11, matching whatever wrote the current lock. npm 10.9.8, which `node:22` ships, silently drops the 32 `"libc"` entries and turns a 12-line diff into a 108-line one. CI consumes it with 10.9.8 either way. ## Verification Run with CI's own toolchain (node 22 / npm 10.9.8), not just a convenient one: - `npm ci` — clean - `npm run lint` — 0 errors (the single `react-hooks/exhaustive-deps` warning is pre-existing on `main`) - `npm test` — 43 files, **465 tests passed** - `npm run build` — succeeds - audit gate (`npm audit --omit=dev` + `audit-allowlist.mjs`) — clean - `docker build --target frontend-prod` — succeeds (that job also failed on #316) ## Follow-up The override constrains a package that is not in the tree, so it needs to be removed when the frontend moves to Babel 8 — at that point it would hold `@babel/plugin-transform-runtime` back rather than unblock anything. JSON has no comments, so that is recorded under "Important constraints" in `webapp/CLAUDE.md`. Worth expecting: with the override in place, Renovate's artifact step should succeed on future `@vitejs/plugin-react` bumps instead of failing this same way again. 🤖 Generated with [Claude Code](https://claude.com/claude-code)

claude-bot added 1 commit

2026-08-31 20:01:07 +00:00

chore(deps): unblock @vitejs/plugin-react 6.1.1 with a peer override (#316 )

CI / Bot/backend version sync (pull_request) Successful in 52s

Details

CI / Backend lint (ruff) (pull_request) Successful in 59s

Details

CI / Summarisation accuracy eval harness (stub provider) (pull_request) Successful in 1m53s

Details

CI / Docker image build (pull_request) Successful in 1m10s

Details

CI / Frontend tests, audit, and build (pull_request) Successful in 2m29s

Details

CI / Bot tests and audit (pull_request) Successful in 2m39s

Details

CI / Backend migration, tests, and audit (pull_request) Successful in 9m4s

Details

54bb60d6a1

#316 had failed identically across six runs — 7173, 7320, 7417, 7502, 7581,
7719 — and would have kept failing on any number of retries. It is unrelated to
the runner-disk problem that was failing the other Renovate PRs.

The branch carried package.json at 6.1.1 and package-lock.json still at 6.0.5.
The PR's own renovate/artifacts failure was the cause, not a symptom: Renovate
could not regenerate the lockfile, so it pushed the manifest bump with a stale
lock and CI could not install.

6.1.1 declares @rolldown/plugin-babel as an *optional* peer. Its own optional
peer @babel/plugin-transform-runtime resolves to 8.0.1, which peers on
@babel/core@^8; the tree has 7.29.7. npm chases that chain during incremental
resolution and gives up with ERESOLVE — even though it installs none of those
packages. The override tells npm to keep that speculative resolution on the 7.x
line, and the update goes through.

Two alternatives were tested and rejected:

- Waiting for lockFileMaintenance to refresh the lock first does NOT help. After
  a clean from-scratch regen at 6.0.5, the incremental bump to 6.1.1 hits the
  identical ERESOLVE. The conflict is not stale transitive versions; it is npm
  declining to re-plan around a pinned package.
- A full from-scratch regen with 6.1.1 does work, but rewrites 61 transitive
  versions (0 added, 0 removed — all @rollup/* and @rolldown/* platform binding
  drift). That is lockFileMaintenance's job, not a single-dependency PR's.

The override gets the lockfile diff down to just the plugin: its version,
integrity, and its own peer metadata (6.1.1 adds oxc-transform-react as a new
optional peer). @babel/core stays at 7.29.7.

Regenerated with npm 11 to match whatever wrote the current lock — npm 10.9.8,
which node:22 ships, silently drops the 32 "libc" entries and turns a 12-line
diff into a 108-line one. CI consumes it with 10.9.8 either way.

Verified with CI's own toolchain (node 22 / npm 10.9.8): npm ci clean, ESLint 0
errors (the one react-hooks/exhaustive-deps warning is pre-existing on main),
43 test files / 465 tests passed, vite build succeeds, audit gate clean, and
the frontend-prod Docker image builds.

The override is documented in webapp/CLAUDE.md, including that it must be
removed when the frontend moves to Babel 8 — JSON has no comments, which is the
only reason that note lives there rather than beside the entry.

Supersedes #316.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

claude-bot merged commit 03ca81c0c3 into main

2026-08-31 20:10:52 +00:00

claude-bot deleted branch fix/316-plugin-react-6.1.1

2026-08-31 20:10:53 +00:00

claude-bot referenced this pull request from a commit

2026-08-31 20:10:54 +00:00

Merge PR #471: unblock @vitejs/plugin-react 6.1.1 with a peer override (#316)

claude-bot referenced this pull request

2026-08-31 20:11:13 +00:00

chore(deps): update dependency @vitejs/plugin-react to v6.1.1 #316