[claude]

This bumps vitest and @vitest/coverage-v8 from ^5.0.1 to ^5.0.5, which pulls @vitest/mocker, @vitest/spy and the @vitest/istanbul-lib-* packages along with vitest's own updated dependencies in the lockfile. Vitest 5.0.5 carries the fix for GHSA-p458-7748-mcp3, which affects @vitest/ui and @vitest/browser; this repo doesn't use either, so it wasn't actually exposed and this keeps the vitest family in step. Build, lint, all 57 tests and the coverage run pass locally.

---

Generated by Claude Code

[socket-security]

Review the following changes in direct dependencies. Learn more about Socket for GitHub.

Diff	Package	Supply Chain Security	Vulnerability	Quality	Maintenance	License
	@​vitest/​coverage-v8@​5.0.1 ⏵ 5.0.5	+1		+1
	vitest@​5.0.1 ⏵ 5.0.5			+1	+1

View full report

[claude]

I reviewed this PR and didn't find any bugs. A code owner still needs to look, because the CODEOWNERS wildcard covers these files. The lockfile also changes more than the description says.

What was reviewed:

• Checked package.json against yarn.lock: vitest, @ vitest/coverage-v8, @ vitest/mocker and @ vitest/spy all resolve to 5.0.5, and the peerDependencies agree.
• Checked that every new dependency range has a lockfile entry, including tinyexec ^1.3.1, chai ^6.3.0, tinybench ^6.2.2 and magic-string ^1.4.3. Removed entries like siginfo and stackback have nothing else depending on them.
• Transitive dependencies with major or loosened versions that the description doesn't mention: obug goes from 2.x to 3.0.0, why-is-node-running goes from 2.3.0 to 3.2.1 (pinned), and tinybench/tinyexec change from exact pins to caret ranges. All of these are test-tooling only.

Extended reasoning...

The change touches only package.json and yarn.lock. It raises the vitest and @ vitest/coverage-v8 dev dependencies from ^5.0.1 to ^5.0.5 and regenerates their transitive tree. No runtime dependencies or application code change, so it touches no security-sensitive surface. The lockfile is internally consistent. The deciding fact is that .github/CODEOWNERS assigns every path (*) to code-owner teams, so approval belongs to them. A smaller factor is that the transitive bumps include two major-version jumps, obug and why-is-node-running.