fix: resolve @testing-library/jest-dom from the project root - #364

Fixes #231

Problem

getJestDomExport used the plugin's own require (created from import.meta.url), so the check was "can vite-plugin-solid reach @testing-library/jest-dom/vitest?". With pnpm's isolated node_modules that is true whenever another package in the tree (Storybook in the issue) depends on jest-dom transitively, because pnpm links the optional peer next to the plugin. Vitest, however, resolves bare setupFiles specifiers from the project root, where @testing-library/jest-dom is not installed, so the injected setup file fails with Failed to load url .../@testing-library/jest-dom/vitest.

Fix

Probe with a require created from the project root (userConfig.root, falling back to process.cwd()), so the setup file is only injected when the project itself can resolve jest-dom. That matches the intent of an optional peer dependency: you opt in by installing it.

The bare specifier is still what gets injected. I tried injecting the resolved absolute path as extra hardening, but require.resolve picks jest-dom's CommonJS entry (dist/vitest.js), which Vitest rejects with "Vitest cannot be imported in a CommonJS module using require()". Vitest resolving the specifier itself lands on the ESM entry. There is a comment explaining this next to the code.

Verification

• Called the built plugin's config hook with mode: 'test' from a Node script. With root set to this repo (jest-dom installed) it injects @testing-library/jest-dom/vitest; with root set to an empty project it injects nothing, even though the plugin itself can still resolve jest-dom. That second case is the issue's scenario.
• Ran a temporary non-browser Vitest test in examples/vite-7 against src/index.ts asserting expect(null).toBeInTheDocument is a function. It passes, so the injected setup file loads.

🤖 Generated with Claude Code