This PR was opened by the Changesets release GitHub action. When you're ready to do a release, you can merge this and the packages will be published to npm automatically. If you're not ready to do a release yet, that's fine, whenever you add more changesets to next, this PR will be updated.

⚠️⚠️⚠️⚠️⚠️⚠️

next is currently in pre mode so this branch has prereleases rather than normal releases. If you want to exit prereleases, run changeset pre exit on next.

⚠️⚠️⚠️⚠️⚠️⚠️

Releases

@solidjs/vite-plugin@3.0.0-next.44

Minor Changes

• 22858a3: start.node: the build emits a ready-to-run Node server. With start: { node: true } the ssr build writes dist/server/node.js beside server.js — node dist/server/node.js (env PORT, default 3000, and HOST) serves the client build statically (files under build.assetsDir as Cache-Control: public, max-age=31536000, immutable, everything else public, max-age=0, must-revalidate with Last-Modified; a reasonable MIME table, HEAD, dot-segment paths and .. traversal refused) and hands every other request to handleRequest with the raw Node request as nativeEvent, so getRequestEvent().nativeEvent answers the same as under vite dev and vite preview. The node<->web bridge is the plugin's own src/http.ts — the code the dev and preview middlewares already run (HTTP/2 pseudo-headers, https: on TLS sockets, client disconnects as the request's AbortSignal, HEAD short-circuit, set-cookie split, backpressure that also settles on close) — shipped as a separate build artifact of the package (dist/node-entry.mjs) that the plugin reads at build time and emits under a small generated header carrying the emit-time constants (client dir relative to the server dir, assetsDir, base, the mode). The file is ESM with no dependency beyond node:* and ./server.js, listens only when run directly, and exports listener (the (req, res) function, mountable into http.createServer, Express, Fastify), createListener({ static?, event? }) — static: false leaves files and the client-mode index.html fallback to a framework such as express.static or a CDN and keeps only the bridge; event: (req) => fields merges extra request-event fields over { nativeEvent: req } — and serve({ port?, host?, static?, event? }).

  Why: the fullstack templates shipped a hand-written server.js whose bulk was this generic Node bridge, copied into every scaffold and baked into the CLI, so bridge fixes never reached users — and it looked custom-made. Node is the one mainstream runtime without a fetch-shaped server API (Workers, Deno, Bun, Netlify, Nitro consume the server bundle's { fetch } directly), so the gap is Node-only and belongs in the build output. It is a start.* option, not ssr.* (ssr stays boolean-only), and applies to both start modes: SSR mode renders pages; client mode with serverFunctions (which keeps dist/server) serves the static client with an index.html history fallback for HTML navigations plus the endpoint. node.js is an emitted asset, never a second build input — server.js and its handleRequest / { fetch } contracts are unchanged, and nothing changes without the option. Where no server bundle exists (client mode without serverFunctions, or start.external) the build warns and emits nothing. Compression/proxy stance unchanged: plain HTTP, put a reverse proxy or CDN in front. Follow-ups this unlocks: the templates drop server.js and point their start script at node dist/server/node.js; create-solid drops its baked SERVER_JS constant.

Patch Changes

• 7fa5aa3: Avoid overriding environments configured in Vitest workspaces and projects with the jsdom default (forward-port of Avoid overriding environments configured in Vitest workspaces #323 by @carloitaben, fixes Test environment detection doesn't consider Vitest workspaces #205). A root config that defines test.projects (or the pre-Vitest-4 test.workspace) runs no tests itself, so it no longer gets test.environment: 'jsdom' injected — which made Vitest probe for (and prompt to install) jsdom at startup even when every project runs under node or in browser mode. Each project keeps controlling its own environment.

• d30f051: Only inject the @testing-library/jest-dom Vitest setup file when the package resolves from the project root (forward-port of fix: resolve @testing-library/jest-dom from the project root #364 by @brenelz, fixes Check for @testing-library/jest-dom doesn't guarantee it's safe to use as setupFiles in Vitest #231). Previously the check ran from the plugin's own location, so with pnpm a transitive jest-dom (for example via Storybook) made Vitest fail with Failed to load url .../@testing-library/jest-dom/vitest. The probe now walks node_modules up from the Vite root the way Vitest resolves bare setupFiles — deliberately ignoring NODE_PATH, which pnpm's bin shims (pnpm vitest) point at the hoisted virtual store where every transitive dependency is reachable.

• 2e79544: Require solid-js / @solidjs/web 2.0.0-rc.9 (peer floor) and compile with @solidjs/compiler / @solidjs/babel-plugin rc.9 — runtime and compiler move in lockstep. The rc.9 compilers emit output only the rc.9 runtime understands, so this floor is a hard requirement, not policy: native elements with several spread sources compile to the runtimes' array form (spread(el, [a, b], …) on the client, ssrElement(tag, [a, b], …) on the server — no mergeProps() proxy, no memo, no hydration id; #3418/#3419/#3423) which only rc.9's @solidjs/web accepts; delegated event handlers move off Solid 1's $$<type> element key onto _$$<type> in both compiled output and the runtime's document delegate, so an rc.8 runtime would never fire an rc.9-compiled onClick (and vice versa); and under componentNames — which the plugin already turns on for its dev and observe postures — SSR output keeps createComponent(Comp, props, "Comp") so the server runtime's observe/dev tier labels the owner and a server finding's ownerPath reads <App> › <Page> like the client's. Nothing in the plugin itself had to change for rc.9: the new observe / development export conditions on @solidjs/web's server-functions and frames client entries (and observe on every server entry) are picked up by the condition lists the plugin already installs, and the new solid-js/internal subpath is covered by the existing solid-js inlining.

• 256c25d: start.instrument: a server-only module the plugin runs to completion before anything else in the server graph loads — the app, the middleware, @solidjs/web, every dependency. The seam for instrumentation that must patch the runtime before the modules it patches are loaded (an APM's OpenTelemetry setup, a profiler, a module.register hook), honored on every surface: vite dev, vite build, vite preview, and a host consuming the handler entry. Replaces the per-host node --import instrument.mjs dance.

  Import order cannot do this in ESM — static imports are hoisted and evaluated in dependency order — so the generated handler entry becomes await import(instrument); await import(handler), with the handler's surface (handleRequest, the fetch default) re-declared by name. The module may be async and needs no exports; the server build must keep code splitting on (the default).

  Also: the componentNames note in the compiler options no longer calls the labels DOM-only — the SSR generate emits them too from the compilers that carry feat(compiler,babel-plugin,solid): componentNames for SSR output; ssrScope swaps the id-bearing owner solid#3441 (2.0.0-rc.9), and the start-ssr suite gains an observe mode that asserts an observe: true production build resolves the observe artifacts and carries component labels (the SSR half asserted once the workspace rides an rc that emits them).