solid-vite-plugin

CSS imported only below a module-level boundary is not delivered to the browser in production SSR start mode with . The server component's HTML is present, but its CSS is absent on both document loads and subsequent frame requests. Plain Vite reproduces this without Cloudflare or Vite+. Versions tested Published: , , , , and 2.0.0-rc.15; 3.0.0-next.50. Source builds of both branches: solidjs/solid: 2aa9e86ada5beb33211f60260c59234bbcf14899 (local Signals, Solid, Web/frames, Babel plugin, and a locally compiled native compiler). solidjs/solid-vite-plugin: ec6b58d0c17290d6f474a9ed93bfa03d1dc9b8a0. Both: plain 8.3.4, Bun 1.4.2, Node 26.12.0, macOS arm64; browser checks with 1.64.1 and system Google Chrome 155.0.8059.85 (). The published versions were resolved from , , and ; the plugin's tag currently points to an older release. Minimal reproduction Start with an empty directory and containing , then: No authored entries, router, custom manifest, exclusions, or settings are required. For the linked HEAD package check, I used to disable the optional devtools detected in the plugin checkout; the production result is the same. Steps and results The following results are the same for the published packages and the two source-built HEADs: 1. Build: . Expected: the server component's stylesheet is available as a browser-served asset (or inline CSS) and represented in the relevant asset collection. Actual: no notes CSS under , no notes CSS entry in . With plain Vite's default SSR asset settings, this minimal repro emits no standalone CSS under either. The CSS Module variant still embeds the hashed class string in the server output. 2. Production document: , then open in a fresh browser context. Expected: red notes. Actual: HTTP 200, raw SSR HTML contains , but no stylesheet link or inline rule; is *. Boot makes zero requests, so document adoption itself works. 3. Production client navigation: in another fresh browser context, open and click Page B. Expected: red notes, with styles delivered before reveal if they were not already loaded. Actual: a successful response from contains , , , but no record / . The element appears with black text. There are no page/console errors in these production checks. 4. Dev: run and repeat both browser paths. Actual: both are red*. The initial document inlines the notes stylesheet in a `import css from './notes.module.css'class={css.notes}_notes_5xr5i_1.cssimport './notes.css'src/App.tsxcssrgb(255, 0, 0)serverFunctionsstartstart.css.filtervirtual:solid-manifestcss.filtervirtual:solid-manifestassetsstylesmeta.preloadsassets.stylescreateServerReference(...)./notesoptimizeDeps.exclude`; this repro uses no exclusions and produces valid component HTML. Existing #414/#415 concern dev manifest timing/cache, and #425 concerns CSS ordering; those do not cover this production omission.

Versions: , , , (first seen on rc.10 / next.46). Repro Run , load , then click . The boundary is not in the document, so it mounts after boot. Expected: the panel mounts, as it does without the . Actual: returns with the right chunks, but the call resolves to and nothing mounts. A document-SSR'd (adopted) boundary still works, and + work too. Cause With , the plugin force-includes and (, the entry) so that both share one instance of the transport config module. But imports **. When the app excludes , that subpath is neither included nor resolved to the optimized module: → , which loads the raw node_modules file. Compiled function references → , which loads . That gives two instances of the server-functions client. calls on one of them, while the references call the other, which has no handler. The frame-stream response is therefore decoded as plain data. Without the , the frames bundle imports and everything shares one instance. Excluding is common in apps that pin or link Solid. Workaround Suggested fix When , also force-include . Alternatively, have import the same specifier the references use.

Summary In test mode the plugin only returns its config when it also sets . When the user config already lists in , the plugin skips and drops the whole block with it, so Vitest gets neither the environment nor the setup file. Component tests that rely on the DOM or on jest-dom matchers then fail. This started with #183, which moved the config into a fresh object but kept as the condition for returning it. Changes Return whenever it has any key, the same check the branch uses. Add a script, a root and , and run the unit tests in the Vitest workflow. Add a patch changeset. Testing : 2 passed. With the change reverted, the new external case fails (). and Prettier pass. Fixes #454