[max-blacksmith]

Bug fix + tests — a project whose vitest differs from the one @useblacksmith/vitest@0.5.0 resolves beside itself in node_modules no longer fails every test file with Vitest failed to find the current suite. Nothing changes for a project where the two resolve to the same copy.

Problem

0.5.0's setup file record-reads.js does import { afterAll } from 'vitest' (#12). Vitest externalizes modules under node_modules, so Node resolves that vitest from the plugin's directory. In a pnpm workspace where two packages depend on the plugin with different peer sets (different @types/node majors was enough), pnpm keeps one @useblacksmith/vitest@0.5.0(vitest@5.1.0) instance whose vitest symlink points at one package's copy. The other package's tests then call a second vitest instance's afterAll, outside any suite, and every test file fails before it runs:

Error: Vitest failed to find the current suite. One of the following is possible:
- "vitest" is imported directly without running "vitest" command
...

0.4.0's setup file imported nothing from vitest, so it was unaffected. --pool=forks does not help; server.deps.inline: [/@useblacksmith\/vitest/] in the consumer's config does.

Fix

The plugin's config() hook adds its own package to test.server.deps.inline, so Vite transforms record-reads.js and resolves its vitest import the same way it does for the test files: to the copy running them.

...(inlineAll ? {} : { server: { deps: { inline: ['@useblacksmith/vitest'] } } }),

inlineAll guards a consumer with inline: true, where merging a list would produce [true, '@useblacksmith/vitest'].

Evidence

New test installed under node_modules copies dist/ and package.json into the fixture's node_modules/@useblacksmith/vitest, places a second copy of vitest under it, and loads the plugin as '@useblacksmith/vitest'. Without the fix it fails with the error above (15 of 16 test files not recorded); with it the full run passes and a changed fixture reruns only its test, so reads are still recorded through the inlined setup file.

Risks

• Inlining means Vite transforms the plugin's two runtime modules (record-reads.js, its vitest import) once per worker instead of Node loading them natively; they are small and have no other dependencies.
• A consumer who already lists other packages in server.deps.inline gets ours appended by Vite's config merge; one who sets inline: true is left alone.

Link to Devin session: https://app.devin.ai/sessions/908e16d5e5d54e2c968498f368f535d8
Open in Devin Desktop: https://app.devin.ai/desktop/session/908e16d5e5d54e2c968498f368f535d8?variant=devin
Requested by: @max-blacksmith

---

^{Open in [code]smith · Need help on this PR? Tag @codesmith-bot with what you need. (Staging)}

---

^{Open in [code]smith · Need help on this PR? Tag @codesmith-bot with what you need.}

---

🟢 Devin Review found nothing to fix · View findings

[devin-ai-integration]

I'll fix CI failures and address comments from users with write access. I'll skip comments containing "(aside)".

• Disable automatic comment, CI, and merge conflict monitoring

[devin-ai-integration]

✅ Devin Review: No Issues Found

Devin Review analyzed this PR and found no bugs or issues to report.

[blacksmith-staging]

Two vitest copies in a pnpm workspace

In a pnpm workspace where the plugin's vitest is the other package's copy, every test file failed with "failed to find the current suite" before; after, all pass and editing one fixture reruns only its test.

_Merge-base

_{This PR 31613ce5}

_{Proof on 31613ce5 · Did Proof get it right? Yes · No}

View full Proof report · React 👎 or comment @codesmith dismiss this proof to dismiss

[blacksmith-sh]

Plugin under a pnpm workspace with two vitest copies

In a real pnpm workspace sharing one plugin copy, the package with the other vitest went from every file failing with "failed to find the current suite" to passing, and --changed then reran only the test whose input changed. The package on the same copy passed on both.

_Merge-base

_{This PR 31613ce5}

_{Proof on 31613ce5 · Did Proof get it right? Yes · No}

View full Proof report · React 👎 or comment @codesmith dismiss this proof to dismiss