Skip to content

fix(vitest): resolve each inline project's own config under Vitest 5 - #370

Open
brenelz wants to merge 1 commit into
nextfrom
fix/369-inline-runtime-client-tests
Open

brenelz wants to merge 1 commit into
nextfrom
fix/369-inline-runtime-client-tests

Conversation

@brenelz

@brenelz brenelz commented Sep 20, 2026

Copy link
Copy Markdown
Contributor

Fixes #369.

Under Vitest 5, inline projects in a test.projects workspace lost everything the plugin injects in test mode. A test.environment: 'node' project kept the root's browser condition, so isServer was false. A jsdom project lost the @testing-library/jest-dom setup file and failed with Invalid Chai property: toBeInTheDocument. It also lost the solid-js server.deps handling.

Root cause

Vitest 5 defaults test.sharedViteServer to true. An inline project that only changes test options reuses the root Vite server, and its options are resolved from the root test block that vitest:capture-raw-test-config captures before any plugin config hook runs. The plugin picks the client or server posture and adds its test.* 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 browser condition. I could not reproduce that exact symptom, but the workspace shape from the issue reproduces the shared-server failure above, and sharedViteServer: false alone fixes it.

Change

When the root config declares test.projects and leaves test.sharedViteServer unset, the config hook sets it to false, 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.deps values. 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: true projects (jsdom and node), vitest@5.0.1, vite@8, solid-js/@solidjs/web 2.0.0-rc.9, @solidjs/testing-library@1.0.0-beta.3, and the plugin installed from pnpm pack. The tests assert isServer in each project, a testing-library render, and a jest-dom matcher.

  • Before, npx vitest run on 5.0.1: 2 failed, 2 passed. After: 4 passed.
  • 4 passed also with pool: 'threads' plus isolate: false, and with projects that omit extends.
  • Vitest 4.1.11: 4 passed before and after.
  • npx tsc --noEmit -p . is clean, and the examples/start-ssr VITEST_PROJECTS=1 suite 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

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-bot

changeset-bot Bot commented Sep 20, 2026

Copy link
Copy Markdown

🦋 Changeset detected

Latest commit: ec6c4dc

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package
Name Type
@solidjs/vite-plugin Patch

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

@pkg-pr-new

pkg-pr-new Bot commented Sep 20, 2026

Copy link
Copy Markdown

Open in StackBlitz

npm i https://pkg.pr.new/@solidjs/vite-plugin@370

commit: ec6c4dc

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant