build(deps): refresh compatible tooling and Node setup

[steipete]

What Problem This Solves

Refresh development and CI dependencies from #53 and #54 while preserving supported Node 25 development installs.

User Impact

No router behavior, public exports, package version, or runtime requirements change. Contributors get the current formatter and linter, and CI uses the updated Node setup action.

Why This Change Was Made

Update oxfmt to 0.72.0, oxlint to 1.87.0, and the pinned actions/setup-node action to 7.1.0. These updates are past the two-day dependency cooldown. Retain tsdown 0.22.14 and its compatible declaration-generator graph: tsdown 0.23.0 excludes Node 25, which this repository explicitly supports with strict engine checks. Vitest 5 likewise excludes Node 25 and is deferred.

Supersedes #53 and #54. Thanks @dependabot for the dependency updates.

Evidence

• Linux, Node 24.19.0, pnpm 11.27.1: pnpm install --frozen-lockfile && pnpm run check passed, including all 58 tests, formatting, build/declarations, typecheck, lint, and packed-package install/import validation.
• actionlint and git diff --check passed.
• Independent Codex autoreview completed with no actionable P0–P2 findings.
• CI at exact head 5ae6a4dc7fb63597926d81802caaad1e05b2c6e6 passed all seven Node/OS jobs: Node 22/24 across Linux, macOS, and Windows, plus Node 25 on Linux. The Node 25 job passed frozen installation and the full package check. Workflow lint and CodeQL also passed.

[clawsweeper]

🦞👀
ClawSweeper picked this up.

Pull request received. I will update this pull request when review starts.

ClawSweeper review complete

ClawSweeper finished reviewing this revision. The review result is being finalized.

View the workflow run.

[clawsweeper]

Codex review: needs maintainer review before merge.

What this changes

This PR updates the formatter, linter, and pinned Node setup action while retaining Node 25-compatible build tooling.

Example: A contributor installs development dependencies on Node 25.

• Before: The lockfile selects oxfmt 0.71.0 and oxlint 1.86.0.
• After: The lockfile selects oxfmt 0.72.0 and oxlint 1.87.0 while retaining tsdown 0.22.14.

Review scores

Measure	Result	What it means
Overall readiness	🧂 unranked krab (1/6)	The patch is focused and has passing validation with no actionable findings, but the applicable contributor execution-proof gate remains unmet.
Proof confidence	🧂 unranked krab (1/6)	Real behavior proof is not required for maintainer- or bot-authored pull requests.
Patch quality	🐚 platinum hermit (4/6)	No actionable review findings were identified.

Product

Kind: Maintenance · Worth it: Yes · Fix scope: Complete
User problem: Contributors need updated development tools without losing supported Node 25 installation compatibility.
Reason: The small maintenance change follows the established dependency-update policy and preserves runtime, export, and build-tool compatibility contracts.

Merge readiness

✅ Ready for maintainer review

Keep this PR open: it provides a focused tooling refresh absent from current main, preserves Node 25 support, and introduces no actionable code defect found in this review.

Priority: P3
Reviewed head: 5ae6a4dc7fb63597926d81802caaad1e05b2c6e6

Before merge

None.

Findings

None.

Tests

• Missing end-to-end proof: Provide terminal output or redacted logs showing a Node 25 frozen install followed by the updated formatter and linter running successfully.

Agent review details

How this fits together

Package metadata and the lockfile select development tools; CI and release workflows install Node and pnpm dependencies before validating or publishing the package.

flowchart TD
  A[CI and release workflows] --> B[Pinned Node setup action]
  B --> C[Frozen pnpm install]
  D[Package metadata and lockfile] --> C
  C --> E[Package quality checks]
  E --> F[Validated package output]

Loading

Technical review

Best possible solution:

Land the compatible tooling refresh while retaining the established Node support contract.

Do we have a high-confidence way to reproduce the issue?

This is dependency maintenance; source and registry metadata verify that the selected versions retain the declared Node compatibility.

Is this the best way to solve the issue?

The focused refresh preserves the documented compatibility boundary and avoids the incompatible bundler update present in the grouped dependency PR.

AGENTS.md: found and applied where relevant.

Codex review notes: model internal, reasoning medium; reviewed against 01c7a1b96886.

Provenance checked

• Formatter and linter dependency selection keeps the original intent (07fab05: The earlier formatter refresh deliberately retained the Node 25-compatible bundler dependency graph.)
• Strict engine checks and supported development installs keeps the original intent (2c380f7: Restore effective pnpm 11 engine enforcement while retaining dependencies compatible with Node 25.)
• Pinned Node setup in CI and releases keeps the original intent (f4138d1: Refresh the toolchain and workflows using pinned action commits.)

Testing

Proof path: unit tests only.

Security

None.

Evidence

What I checked:

• Verified introduced changes: The pinned base-to-head diff changes only two setup-node pins, formatter and linter versions with their lock entries, registry deprecation metadata, and one changelog entry; runtime source, exports, scripts, and the Node engine contract remain unchanged. (package.json:54, 5ae6a4dc7fb6)
• Preserved compatibility decision: CONTRIBUTING.md explicitly requires Node 25 development installs; prior work in build(deps): refresh formatter with Node 25 support #48 and build(deps): refresh Node types and cover Node 25 installs #52 retained compatible build dependencies, and this PR preserves that choice. (CONTRIBUTING.md:15, 01c7a1b96886)
• Exact-head validation: All twelve checks passed for the reviewed head, including Node 22/24 across Ubuntu, macOS, and Windows and Node 25 on Ubuntu; the Node 25 job reports successful setup, frozen installation, and package checks. (.github/workflows/ci.yml:58, 5ae6a4dc7fb6)
• Dependency contract verification: npm registry metadata for oxfmt 0.72.0 and oxlint 1.87.0 matches the lockfile integrity values, declares Node ^20.19.0 || >=22.12.0, and contains no package lifecycle scripts. (pnpm-lock.yaml:1023, 5ae6a4dc7fb6)
• Executable dependency and pin verification: Both changed workflows execute this action, establishing the dependency contract boundary; the v7.1.0 tag resolves to the exact pinned commit, and inspected source changes cover version-file parsing, manifest retries, and installed Node validation. (src/distributions/official_builds/official_builds.ts, 949feb2413d6)
• Related update ownership: The PR explicitly consolidates build(deps-dev): bump the development group with 3 updates #53 and build(deps): bump actions/setup-node from 7.0.0 to 7.1.0 in the actions group #54, crediting Dependabot while excluding the former's Node 25-incompatible tsdown update.

Labels

Label changes:

• add P3: Routine development-tool and workflow maintenance with no demonstrated router runtime regression.
• add rating: 🧂 unranked krab: Overall readiness is 🧂 unranked krab; proof is 🧂 unranked krab and patch quality is 🐚 platinum hermit.
• add status: 👀 ready for maintainer look: ClawSweeper has no concrete contributor-facing blocker left for this PR.

Label justifications:

• P3: Routine development-tool and workflow maintenance with no demonstrated router runtime regression.
• rating: 🧂 unranked krab: Overall readiness is 🧂 unranked krab; proof is 🧂 unranked krab and patch quality is 🐚 platinum hermit.
• status: 👀 ready for maintainer look: ClawSweeper has no concrete contributor-facing blocker left for this PR.

Rating scale

6/6 🦀 challenger crab · 5/6 🦞 diamond lobster · 4/6 🐚 platinum hermit · 3/6 🦐 gold shrimp · 2/6 🦪 silver shellfish · 1/6 🧂 unranked krab. Overall follows the weaker of proof and patch quality; ✨ marks media proof (a screenshot, video, or linked artifact) that directly shows the changed behavior.

Workflow

ClawSweeper edits this one comment on every review. Comment @clawsweeper re-review for a fresh review only; repair and merge need explicit maintainer commands such as @clawsweeper autofix or @clawsweeper automerge.

Reviewed October 10, 2026, 5:10 AM ET / 09:10 UTC.