Conversation
Vitest 5 defaults test.sharedViteServer to true, so inline projects reuse the root Vite server and never run the plugin's config hook. They lost the per-project posture, the jest-dom setup file and the server.deps handling. The plugin now sets sharedViteServer to false when the root config declares test.projects and the user has not set the option. Fixes #369
🦋 Changeset detectedLatest commit: ec6c4dc The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
commit: |
ryansolid
left a comment
There was a problem hiding this comment.
Reproduced and verified — the code change is correct and I'd merge it, but the issue link needs changing.
What this fixes: under Vitest 5, inline
test.projectsshare the root Vite server by default and take theirtestoptions fromvitest:capture-raw-test-config, which snapshots the roottestblock before any pluginconfighook runs. So a shared project never sees this plugin's posture,jest-domsetup file, orserver.deps.getOwnServerReasonreadssharedViteServerfrom the resolved root config, so returningfalsefrom the hook is honored. Confirmed with a two-project repro onvitest@5.0.2(2 failed → 4 passed; explicittruerespected; Vitest 4.1.11 unchanged).environmentisn't in Vitest'sVITE_AFFECTING_TEST_OPTIONS, so there's no narrower condition available — agreed with the PR's reasoning.What it doesn't fix: #369 as reported. The reporter's follow-up says the symptom is Deno-only — Deno resolves the externalized testing-library's
@solidjs/webimport withdeno/nodeconditions, both of which map todist/server.js. On Node the testing-libraryrenderalready passes onnext. Please change "Fixes #369" → "Refs #369" (PR body, commit, changeset first sentence); we can decide separately whether #369 stays open as a Deno item.Small asks:
- Add a
resolveConfig-level assertion inexamples/start-ssr/test/run.mjsbeside theprojects-envcheck:sharedViteServerisfalsewhenprojectsis declared,undefinedotherwise, preserved when explicit. Version-independent, so it covers this without a Vitest 5 example.- Expand the code comment at
src/index.ts:1195to name the raw-capture mechanism, so the condition isn't narrowed later.- README: mention that
truealso drops theserver.depshandling, and that this trades Vitest 5's shared-server optimization for Vitest 4 behavior.- Changeset could be a couple of sentences rather than the full PR body.
No overlap with #371 — hunks are disjoint and a trial merge is clean.
— Claude via Cursor
Fixes #369.
Under Vitest 5, inline projects in a
test.projectsworkspace lost everything the plugin injects in test mode. Atest.environment: 'node'project kept the root'sbrowsercondition, soisServerwasfalse. A jsdom project lost the@testing-library/jest-domsetup file and failed withInvalid Chai property: toBeInTheDocument. It also lost thesolid-jsserver.depshandling.Root cause
Vitest 5 defaults
test.sharedViteServertotrue. An inline project that only changestestoptions reuses the root Vite server, and its options are resolved from the roottestblock thatvitest:capture-raw-test-configcaptures before any pluginconfighook runs. The plugin picks the client or server posture and adds itstest.*values in that hook, so none of it reaches a shared project. Vitest 4.1.11 resolves a Vite config per project and is not affected.The issue describes this as externalized dependencies missing the
browsercondition. I could not reproduce that exact symptom, but the workspace shape from the issue reproduces the shared-server failure above, andsharedViteServer: falsealone fixes it.Change
When the root config declares
test.projectsand leavestest.sharedViteServerunset, theconfighook sets it tofalse, so every project resolves its own Vite config as it did under Vitest 4. An explicit user value is respected. Vitest reads the option from the resolved root config (getOwnServerReason), so setting it from a plugin hook is enough.A narrower condition, such as disabling sharing only when project postures differ, would not work: a shared project with the same posture still loses the jest-dom setup file and the
server.depsvalues. Conditions are Vite-level, so they cannot vary per project on one server either.The README's vitest section documents the behavior, and a changeset is included.
Verification
Scratch project with two
extends: trueprojects (jsdom and node),vitest@5.0.1,vite@8,solid-js/@solidjs/web2.0.0-rc.9,@solidjs/testing-library@1.0.0-beta.3, and the plugin installed frompnpm pack. The tests assertisServerin each project, a testing-libraryrender, and a jest-dom matcher.npx vitest runon 5.0.1: 2 failed, 2 passed. After: 4 passed.pool: 'threads'plusisolate: false, and with projects that omitextends.npx tsc --noEmit -p .is clean, and theexamples/start-ssrVITEST_PROJECTS=1suite passes (6 tests, Vitest 4.1.11).Left open
No in-repo test runs on Vitest 5, because the examples pin
vitest ^4.1.11. Covering this needs an example and lockfile bump.🤖 Generated with Claude Code