chore(deps): bump vitest + @vitest/coverage-v8 to 5.0.1 (supersedes #9, #4) - #18
Conversation
…it vite Supersedes the separate Dependabot PRs #9 and #4, which had to land together: vitest and @vitest/coverage-v8 are version-locked, and merging either alone breaks the test run. Vitest 5 no longer re-exports vite, so vitest.config.ts failed to type check on the bump alone: vitest.config.ts(2,38): error TS2307: Cannot find module 'vite' vitest.config.ts(13,23): error TS7006: Parameter 'code' implicitly has an 'any' type vitest.config.ts(13,29): error TS7006: Parameter 'id' implicitly has an 'any' type The config imports transformWithEsbuild from vite directly, so vite is now an explicit devDependency pinned to the version already resolved in the lockfile (8.1.5). The implicit-any errors cascade from the failed import and resolve with it. Vitest 5 requires Node 22 and Vite 6.4+. CI runs Node 22 (vitest.yml) and the resolved Vite is 8.1.5, so both floors are met. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Signed-off-by: Andrew Anderson <andy@clubanderson.com>
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
✅ Deploy Preview for hivecommons-docs ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
![hivecommons-hive[bot]](https://avatars.githubusercontent.com/in/3568013?s=60&v=4){kind=small}
There was a problem hiding this comment.
Verified the supersession claim and the diff against the tree; one real failure remains before this can land.
Supersession is genuine. #4 bumps only @vitest/coverage-v8 and #9 bumps only vitest; the two packages are peer-locked (coverage-v8 5.0.1 peer-requires vitest: 5.0.1), so neither can pass alone — I've flagged both for closure in favour of this PR. The explicit vite: ^8.1.5 devDependency is also correct: vitest.config.ts:2 imports transformWithEsbuild from 'vite', and vitest 5 no longer re-exports it, so it should have been a direct dependency all along. Pinning to the already-resolved 8.1.5 keeps the rest of the lockfile still.
Remaining defect: src/__tests__/Mermaid.test.tsx fails under vitest 5 (CI job 107317954371: 444 passed, 1 failed). The failing assertion (Mermaid.test.tsx:33-38) checks that mermaid.initialize was called at module load — the call happens as a top-level side effect in src/lib/Mermaid.tsx:6. Under vitest 4 the vi.mock('mermaid', …) factory's vi.fn() retained that call record by the time the test ran; under 5.0.1 it no longer does (the mock's call history is empty when asserted). The component behaviour is unchanged — this is a test-harness interaction with vitest 5's mock/module lifecycle, and the fix belongs in this PR since it's what makes the suite red. One option: re-import @/lib/Mermaid inside the test after vi.resetModules() so the side effect runs within the test's scope, rather than relying on cross-test module-load ordering.
Everything else checked out: TypeScript & ESLint pass on this head, and the Node 22 / Vite 6.4+ floors claimed in the body match vitest.yml and the resolved lockfile.
— hive: agent=reviewer backend=copilot model=claude-fable-5 copilot=1.0.88
501cbba to
54b39e6
Compare
Vitest 5 changed module evaluation ordering, so the static
`import { MermaidComponent }` at the top of the file is no longer
guaranteed to have been evaluated when the assertion runs. The side
effect under test (`mermaid.initialize`) fires at the top level of
@/lib/Mermaid, so import it explicitly inside the test instead of
depending on that ordering.
444 of 445 tests already passed on vitest 5; this was the only one
relying on the old behaviour.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Signed-off-by: Andrew Anderson <andy@clubanderson.com>
54b39e6 to
aee9a04
Compare
1 participant
What
Bumps
vitestand@vitest/coverage-v8to 5.0.1 together, and addsviteas an explicit devDependency.Supersedes Dependabot PRs #9 and #4.
Why one PR
The two packages are version-locked; merging either alone breaks the test run. Dependabot raised them separately, so neither could pass on its own.
Why
viteis now explicitVitest 5 no longer re-exports
vite, so the bump alone fails type checking:vitest.config.tsimportstransformWithEsbuildfromvitedirectly, so it should have been a direct dependency all along. Pinned to 8.1.5, the version already resolved in the lockfile, so nothing else moves. The implicit-any errors cascade from the failed import and clear with it.Vitest 5 requirements
Node 22 and Vite 6.4+. CI runs Node 22 in
vitest.yml, and the resolved Vite is 8.1.5. Both floors are met.🤖 Generated with Claude Code