@solidjs/testing-library resolves @solidjs/web to the server build (isServer true) in jsdom tests under a multi-project vitest setup
Nobody has claimed this yet.
Assessment
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Newbie friendliness
- 68/100
- Issue type
- Bug
- Clarity
- Clearly specified
- Activity status
- Active
- Tech stack
- node.js, typescript, vite
- Domain
- build-system, testing-qa
Research direction
Start with the plugin's dependency handling for the node/server posture and compare it with the client/jsdom path described in the issue. Reproduce the multi-project Vitest setup, then verify that render and hydrate resolve the browser build without requiring the workaround.
Written by the indexing model from the issue text.
Description
Environment
@solidjs/vite-plugin3.0.0-next.44vitest5.0.1, multi-project (projects),pool: threads,isolate: falsesolid-js/@solidjs/web2.0.0-rc.9@solidjs/testing-library1.0.0-beta.3
Reproduction
A vitest config with two projects, one jsdom ("client") and one node ("server"):
test: {
projects: [
{ test: { name: "client", environment: "jsdom", include: ["src/**/*.test.tsx"] } },
{ test: { name: "server", environment: "node", include: ["src/server/**/*.test.ts"] } },
],
}
In a test file, import { isServer } from "@solidjs/web" is false (correct browser build). But inside @solidjs/testing-library's render, @solidjs/web is the server build (isServer === true), so render/hydrate behave incorrectly.
Root cause
In the client/jsdom test posture the plugin injects browser into resolve.conditions (fixing inlined modules) but leaves @solidjs/web and @solidjs/testing-library externalized — and explicitly externalizes solid-js via test.server.deps.external: [/solid-js/]. Externalized modules are executed natively by Node, whose resolution conditions are ['node', 'import', 'default'] (no browser). So @solidjs/testing-library's own import { render, hydrate } from "@solidjs/web" resolves the node export (dist/server.js).
The plugin already handles the inverse case for the node/server posture by inlining /solid-js/ + /@solidjs[+/]web/, but the client posture gets no equivalent treatment.
Workaround
Inline the runtime packages so their imports resolve through Vite's browser condition:
test: {
server: {
deps: {
inline: ["solid-js", "@solidjs/web", "@solidjs/testing-library"],
},
},
}
(deps.inline takes precedence over deps.external.)
- Dominant language
- TypeScript
- Stars
- 520
- Forks
- 70
- Avg merge
- 23h 35m
- Merged PRs (30d)
- 39
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from solidjs/solid-vite-plugin
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
solidjs/solid-vite-plugin#205 · 1 comment · 2 reactions ·
-
Difficulty 5/5 Over a week Newbie friendliness 35/100
solidjs/solid-vite-plugin#328 ·
-
Difficulty 3/5 1-2 days Newbie friendliness 68/100
solidjs/solid-vite-plugin#308 ·
-
Difficulty 3/5 1-2 days Newbie friendliness 72/100
solidjs/solid-vite-plugin#262 · 2 comments ·
-
Difficulty 3/5 1-2 days Newbie friendliness 65/100
solidjs/solid-vite-plugin#259 · 2 comments · 1 reaction ·
All issues in solidjs/solid-vite-plugin
Similar issues
-
enhancement
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
dennys-bd/agent-hive#184 ·
-
Add: hunch Open
Difficulty 2/5 1-3 hours Newbie friendliness 74/100
AbdelStark/awesome-typesafe#104 ·
-
ai-observability bug team/ai-observability
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
vicharanashala/fln#563 ·