@solidjs/testing-library resolves @solidjs/web to the server build (isServer true) in jsdom tests under a multi-project vitest setup #369

Activity

1. brenelz commented on Sep 20, 2026

   

   brenelz

   on Sep 20, 2026

   Contributor

   More actions

   Thanks for the report. I reproduced a failure with this workspace shape on vitest@5.0.1, and the cause is different from the one described. Vitest 5 defaults test.sharedViteServer to true, so inline projects reuse the root Vite server and never run the plugin's config hook. They lose the per-project client or server posture, the jest-dom setup file, and the server.deps handling. The same config passes on Vitest 4.1.11.

   Until a release includes #370, setting the option in the root config restores the Vitest 4 behavior without the deps.inline list:

   test: {
     sharedViteServer: false,
     projects: [/* ... */],
   }

   I could not reproduce the exact symptom where only @solidjs/testing-library resolves the server build, so if it still happens with sharedViteServer: false, please share the full vitest config.
2. ashtonjurgens commented on Sep 21, 2026

   

   ashtonjurgens

   on Sep 21, 2026

   Author

   More actions

   Apologies, looks like this is deno only. Here's a repro https://gist.github.com/ashtonjurgens/aef5c128b4a24691493d7f2444c21117 . Of course, take the README's AI generated diagnosis/solution with a grain of salt.
3. ryansolid commented on Sep 27, 2026

   

   ryansolid

   on Sep 27, 2026

   Member

   More actions

   Thanks for the Deno follow-up and the gist — that pins it down.

   #370 fixes a separate Vitest 5 regression found while investigating this: inline test.projects share the root Vite server by default, which bypasses the plugin's config hook (the node project lost the server posture and the jsdom project lost the jest-dom setup file). It does not change the Deno resolution path, and on Node the testing-library render in your repro already passes on next.

   Mechanism: the externalized @solidjs/testing-library imports @solidjs/web through Deno's own resolver, whose conditions are deno/node — and @solidjs/web's exports map both of those to the server build (dist/server.js). Under Node, Vitest forwards the root config's browser condition to the worker's --conditions, so externals resolve the browser build; Deno never receives that condition.

   Two candidate fixes:

   • Plugin side: have the client test posture inline the runtime-consuming packages (as the server posture already does), so their @solidjs/web imports resolve through Vite's browser condition rather than the host runtime's.
   • Workaround today: Deno's custom-conditions setting — deno run --conditions browser … or DENO_CONDITIONS=browser (per the current Deno CLI docs; the gist's --node-conditions/DENO_NODE_CONDITIONS naming doesn't appear there). browser precedes deno in the exports map, so it should win — unverified here, Deno isn't installed on this machine.

   Keeping this open, scoped to the Deno resolution path.

   — Claude via Cursor
4. ryansolid

   added a commit that references this issue on Sep 30, 2026

   fix(vitest): address review — resolveConfig assertion, comment, docs …

   ...

   59519fb