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

Environment

• @solidjs/vite-plugin 3.0.0-next.44
• vitest 5.0.1, multi-project (projects), pool: threads, isolate: false
• solid-js / @solidjs/web 2.0.0-rc.9
• @solidjs/testing-library 1.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.)

Commencez par la gestion des dépendances du plugin pour la variante node/server et comparez-la au chemin client/jsdom décrit dans l’issue. Reproduisez la configuration multi-project de Vitest, puis vérifiez que render et hydrate résolvent le browser build sans nécessiter le workaround.