Skip to content

chore(npm)(deps): bump react and @types/react - #516

Open
dependabot[bot] wants to merge 2 commits into
mainfrom
dependabot/npm_and_yarn/multi-9b1536b8cd
Open

dependabot[bot] wants to merge 2 commits into
mainfrom
dependabot/npm_and_yarn/multi-9b1536b8cd

Conversation

@dependabot

@dependabot dependabot Bot commented on behalf of github Aug 24, 2026

Copy link
Copy Markdown
Contributor

Bumps react and @types/react. These dependencies needed to be updated together.
Updates react from 19.2.7 to 19.2.8

Release notes

Sourced from react's releases.

19.2.8 (July 21st, 2026)

React Server Components

Commits

Updates @types/react from 19.2.17 to 19.2.18

Commits

@dependabot
dependabot Bot requested a review from runyourempire as a code owner August 24, 2026 06:10
@dependabot dependabot Bot added dependencies Pull requests that update a dependency file frontend React frontend labels Aug 24, 2026
@dependabot
dependabot Bot force-pushed the dependabot/npm_and_yarn/multi-9b1536b8cd branch 4 times, most recently from b298fd7 to 44fca08 Compare August 30, 2026 05:35
runyourempire added a commit that referenced this pull request Aug 31, 2026
… matrix, remove-by wired (#554)

Lane D of the 2026-08-31 audit remediation: four known CI holes, each
re-verified against live state before touching anything. Two needed
changes (shipped here); two turned out to be already closed on the
current base — documented below so the audit trail reflects what was
actually found, not what the brief assumed.

## Hole 1 — Dependabot NOTICE starvation (FIXED: new `dependabot-notice`
job)

**The hole.** `Repo guards` requires `node scripts/generate-notice.cjs
--check --require` to pass on every PR: third-party attribution must be
regenerated in the same change as any dependency move. Dependabot cannot
run repo scripts, so every cargo or production-npm bump it opens fails
`Third-party attribution is current (NOTICE)` and rots. Verified live at
step level before fixing: PRs #457 (cargo `zip`) and #516 (npm `react`)
both fail exactly that step, every other repo-guards step green. 27
Dependabot PRs are currently open, several ecosystems pinned at their
`open-pull-requests-limit` — the gate had starved automated dependency
updates entirely.

**The fix.** A `dependabot-notice` job in validate.yml, gated
`github.event_name == 'pull_request' && github.actor ==
'dependabot[bot]'`, that completes the commit on Dependabot's behalf:

- Checks out the **PR branch** (`github.event.pull_request.head.ref`),
not the unpushable detached merge ref. Dependabot branches always live
in this repo, never a fork, so the job token can push them.
- Rebuilds NOTICE with the **exact recipe the gate itself uses** (stable
Rust toolchain for `cargo metadata`, `pnpm install --frozen-lockfile
--ignore-scripts` for `pnpm licenses list`), so what it generates is
byte-for-byte what `--check` will verify. Verified end-to-end locally:
that recipe followed by write-mode `generate-notice.cjs` reproduces the
committed NOTICE with zero diff on a current tree, and `git diff --quiet
-- NOTICE` is the correct changed-detector.
- If NOTICE changed: commits it, pushes to the branch, and
**re-dispatches Validate** on the healed head.

Three GitHub mechanics are load-bearing and documented in the job
comment:

1. **Dependabot-triggered runs get a read-only `GITHUB_TOKEN`**
regardless of repo defaults. The job-level `permissions:` block
(`contents: write`, `actions: write`) elevates this job only; every
other job keeps its defaults.
2. **Pushes made with `GITHUB_TOKEN` never trigger workflow runs**
(GitHub's recursion guard). Without compensation the healed commit would
sit forever with no `Validate Success` on it — and the main ruleset's
*sole* required check (verified via `rules/branches/main`: `Validate
Success`, strict) reads the PR's head SHA. `workflow_dispatch` is the
documented exception to the recursion guard, and validate.yml already
runs its full suite on dispatch (the heavy legs' `github.event_name ==
'workflow_dispatch'` clauses), so the job dispatches Validate on the
healed branch tip. Its check runs attach to the new head SHA, which is
what the merge gate reads. Hermetic is deliberately NOT re-dispatched:
the healed commit differs from the already-hermetic-tested head by
NOTICE text only, `Hermetic Success` is not a required check, and a
~20-min two-OS cacheless matrix would spend metered hosted minutes to
learn nothing.
3. **No loop is possible.** The heal push triggers nothing (recursion
guard); in the dispatched run the job skips (neither `pull_request` nor
the Dependabot actor test holds). If Dependabot force-pushes a rebase,
the NOTICE commit is dropped — but that push is a Dependabot-actored
`pull_request` event, so the heal simply runs again on the new head. A
push race with a Dependabot rebase is rejected non-fast-forward and
self-corrects the same way.

`validate-success` now includes `dependabot-notice` in `needs`: it skips
(== pass) on every non-Dependabot PR, but a heal failure on a Dependabot
PR is visible in the aggregate instead of vanishing.

Expected behavior on a healed PR: the original run's `Repo guards` still
fails against the pre-heal commit (correct — that SHA is stale), and the
dispatched run on the healed head goes green and satisfies the ruleset.
Bumps that don't move the shipped closure (dev-dep and actions bumps —
verified on #517/#518) regenerate to no diff, push nothing, and dispatch
nothing.

## Hole 2 — file-size gate skippable on Rust-only PRs (VERIFIED ALREADY
CLOSED — no change)

The brief said `Check file sizes` runs inside the path-filtered Frontend
job. Checked against the current base before acting: it was **moved to
`repo-guards` on 2026-08-14** (the job's own comment documents the
#423/#430 incident), the Frontend job carries a tombstone comment
pointing there, `repo-guards` has no `if:` and no `needs:` so it runs on
every PR and dispatch, and live Dependabot runs show `Check file sizes`
executing and passing inside `Repo guards`. `node
scripts/check-file-sizes.cjs --ci` exits 0 on this tree. Nothing to do;
recorded here so the hole is closed with evidence rather than by
assumption.

## Hole 3 — Hermetic vacuously green on main (HALF ALREADY CLOSED, other
half FIXED: install retry)

**Vacuous-green half: already closed.** The `!cancelled()` wrapper on
`fresh-clone`'s `if:` (documented in-file, with the 2026-08-13/14
observations of 7-9s "successes") already forces the full matrix on
push/schedule/dispatch; the path filter applies only to `pull_request`.
Verified against live runs, not just the YAML: the latest `push` run
built for ~19 min and the latest `schedule` run for ~23 min — real
two-OS cold builds, not 1-second skips. No change.

**Retry half: shipped.** `pnpm install --frozen-lockfile` now retries up
to 3 attempts (20s backoff, `::warning::` per miss, `::error::` on
exhaustion) in **both** places that build better-sqlite3 natively:

- the root install (better-sqlite3 is a direct root dependency), and
- the `mcp-4da-server` install line (a direct dependency there too — the
open 13.x bump PR #446 targets exactly that package; only the install
line is retried, build and tests stay single-shot because a failure
there is real signal).

better-sqlite3 falls back to a node-gyp source build whenever no
prebuilt binary matches the image's Node ABI (the 13.x line in
particular), and that native build flakes on windows-latest. Three
attempts separates network/toolchain weather from a genuine fresh-clone
break; anything still failing after 3 tries IS the finding.

## Hole 4 — `check-remove-by.cjs` unenforced (FIXED: wired into `Repo
guards`)

Shipped in #421 and wired to nothing — verified by grep across
package.json, `.husky/`, and `.github/`: zero references.
(`.husky/pre-commit` runs the *staged-files-only* cousin
`check-dead-code-expiry.cjs`, which covers only `#[allow(dead_code)]`;
the whole-tree `REMOVE BY <date>` gate never ran anywhere, so an expired
marker could never fail anything.) Now a step in `repo-guards` — the
unfiltered job that runs on every PR — invoked as `node
scripts/check-remove-by.cjs --ci` for GitHub annotations. Exits 0 on the
current tree (49 markers, all future-dated, 0 expired, 0 allowlisted),
so this ratchets from a clean baseline.

## Verification performed

- `node scripts/check-file-sizes.cjs --ci` — exit 0
- `node scripts/check-remove-by.cjs` — exit 0 (49 upcoming, 0 expired)
- `pnpm install --frozen-lockfile --ignore-scripts` + `node
scripts/generate-notice.cjs` (write mode) — NOTICE byte-identical,
diff-detector confirmed
- `node scripts/check-workflow-shell-syntax.cjs` — 53 inline scripts
(including the new run blocks) parse cleanly
- Both workflows parsed with a YAML parser (actionlint not installed on
this box); job graphs confirmed: validate = `changes, frontend,
mcp-server, relay, repo-guards, dependabot-notice, rust,
validate-success`; hermetic = `changes, fresh-clone, hermetic-success`
- Live-state checks: ruleset required checks, failing step
identification on #457/#516, passing repo-guards on #517/#518, hermetic
push/schedule run durations

## Out of scope (deliberately untouched)

Frontend job's npx/audit steps and its 30-min timeout; release.yml
(signing owned elsewhere).

## Residual risks, disclosed

- The heal costs ~4-8 hosted-runner minutes per Dependabot PR sync
(toolchain + install + `cargo metadata`); dev-dep bumps pay it only to
conclude "no diff". Acceptable against 27 rotting PRs.
- After the bot pushes to a Dependabot branch, Dependabot treats the PR
as externally modified and stops auto-rebasing it; `@dependabot rebase`
still works and simply re-triggers the heal on the recreated branch.
- The dispatched Validate run executes the FULL suite (dispatch runs all
heavy legs) — heavier than the path-filtered PR run, but the only
dispatch-shaped trigger that exists, and correctness beats economy at a
required gate.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

https://claude.ai/code/session_01LrXvdHoDGUj99Fqf1fCYJY

Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
Bumps [react](https://github.com/react/react/tree/HEAD/packages/react) and [@types/react](https://github.com/DefinitelyTyped/DefinitelyTyped/tree/HEAD/types/react). These dependencies needed to be updated together.

Updates `react` from 19.2.7 to 19.2.8
- [Release notes](https://github.com/react/react/releases)
- [Changelog](https://github.com/react/react/blob/main/CHANGELOG.md)
- [Commits](https://github.com/react/react/commits/v19.2.8/packages/react)

Updates `@types/react` from 19.2.17 to 19.2.18
- [Release notes](https://github.com/DefinitelyTyped/DefinitelyTyped/releases)
- [Commits](https://github.com/DefinitelyTyped/DefinitelyTyped/commits/HEAD/types/react)

---
updated-dependencies:
- dependency-name: "@types/react"
  dependency-version: 19.2.18
  dependency-type: direct:development
  update-type: version-update:semver-patch
- dependency-name: react
  dependency-version: 19.2.8
  dependency-type: direct:production
  update-type: version-update:semver-patch
...

Signed-off-by: dependabot[bot] <support@github.com>
@dependabot
dependabot Bot force-pushed the dependabot/npm_and_yarn/multi-9b1536b8cd branch from 44fca08 to 4355a14 Compare August 31, 2026 09:51
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

dependencies Pull requests that update a dependency file frontend React frontend

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant