Repository navigation
build(deps-dev): bump vitest from 4.1.11 to 5.0.5 - #65
dependabot[bot] wants to merge 1 commit into
Conversation
Bumps [vitest](https://github.com/vitest-dev/vitest/tree/HEAD/packages/vitest) from 4.1.11 to 5.0.5. - [Release notes](https://github.com/vitest-dev/vitest/releases) - [Changelog](https://github.com/vitest-dev/vitest/blob/main/docs/releases.md) - [Commits](https://github.com/vitest-dev/vitest/commits/v5.0.5/packages/vitest) --- updated-dependencies: - dependency-name: vitest dependency-version: 5.0.5 dependency-type: direct:development update-type: version-update:semver-major ... Signed-off-by: dependabot[bot] <support@github.com>
|
🦞👀 Pull request received. I will update this pull request when review starts. ClawSweeper review completeClawSweeper finished reviewing this revision. The review result is being finalized. |
|
Codex review: blocked before merge. What this changesThis PR upgrades the development test runner from Vitest 4.1.11 to 5.0.5 and updates its lockfile dependencies. Example: A contributor runs pnpm install --frozen-lockfile on Node 25.9.0.
Review scores
ProductKind: Maintenance · Worth it: No Regression provenancePossible regression — probable (reviewed change; failure trace). No predecessor PR is attributed. Merge readiness⛔ Blocked before merge - 3 items remain This PR breaks supported Node 25 development installs and contradicts recorded compatibility direction; repository policy does not permit automatic closure of this unimplemented upgrade. Priority: P2 Before merge
Findings
Provenance
Agent review detailsHow this fits togetherVitest runs the router's TypeScript behavior tests during package validation; pnpm validates dependency engines before those tests can start. flowchart LR
A[Contributor checkout] --> B[pnpm frozen install]
B --> C[Dependency engine validation]
C --> D[Package checks]
D --> E[Vitest router tests]
D --> F[Packed package validation]
Technical reviewBest possible solution: Retain Vitest 4.1.11 until an upgrade supports the repository's declared development runtimes. Do we have a high-confidence way to reproduce the issue? The locked Vitest engine range excludes Node 25 under engineStrict, and the exact-head Node 25 job fails during installation while main passes; no target code was executed locally. Is this the best way to solve the issue? This upgrade conflicts with the established compatibility contract; retaining the current test runner is preferable to disabling engine checks or removing supported Node coverage. Full review comments:
Overall correctness: patch is incorrect AGENTS.md: found and applied where relevant. Codex review notes: model internal, reasoning medium; reviewed against 3b2fb01297a5. TestingProof path: in-process harness. SecurityNone. EvidenceWhat I checked:
Likely related people:
LabelsLabel changes:
Label justifications:
Rating scale6/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. WorkflowClawSweeper edits this one comment on every review. Comment Reviewed October 19, 2026, 3:08 PM ET / 19:08 UTC. |
Bumps vitest from 4.1.11 to 5.0.5.
Release notes
Sourced from vitest's releases.
... (truncated)
Commits
7a825dbchore: release v5.0.5 (#11609)6621a72fix: abort all running tests on cancel (#11606)e9c3d72fix: release mocks of finished test files (#11607)8dd67c2fix(browser): run global setup once with instances (#11596)6c5a447fix: run hook cleanups when a later hook fails (#11605)9697b38fix: keep the import frame in native loader errors (#11599)6498b66fix(browser): wait 30s for the browser to close (#11601)f161e6dfix(browser): drop late connections of closed sessions (#11600)fe86a64fix: skip builtin loading in async leak detector (#11598)6ae8e89fix(reporter): end reason'failed'on worker crash (#11568)Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting
@dependabot rebase.Dependabot commands and options
You can trigger Dependabot actions by commenting on this PR:
@dependabot rebasewill rebase this PR@dependabot recreatewill recreate this PR, overwriting any edits that have been made to it@dependabot show <dependency name> ignore conditionswill show all of the ignore conditions of the specified dependency@dependabot ignore this major versionwill close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this minor versionwill close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this dependencywill close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)