Summary
With fileRoutes() from filesystem-routing/vite configured with a routers map and buildInputs, the client entry's CSS chunk is built and recorded in the Vite manifest, but no <link rel="stylesheet"> for it is emitted into the rendered head. Global styles imported by the root component never load.
CSS modules imported by route components are unaffected, so the page comes back partially styled and the build succeeds with no warning or error.
Works on 3.0.0-next.39, broken on 3.0.0-next.40, same source.
Reproduction
minimal repro
npm install
npm run build
npm run check
check.mjs calls handleRequest once against the built server bundle and reports what was built, what the manifest records, and what the head links.
On 3.0.0-next.40:
entry css built: virtual_solid-ssr-entry-client-BII8mvam.css
manifest records it: [ 'assets/virtual_solid-ssr-entry-client-BII8mvam.css' ]
linked in <head>: false
stylesheet links: 1
Expected, and what 3.0.0-next.39 produces from the same source:
linked in <head>: true
stylesheet links: 2
Trigger
fileRoutes({
routers: {
client: new PageFileSystemRouter({ dir, extensions }),
},
buildInputs: "client", // removing this line restores the link
})Both parts are needed. buildInputs on a bare fileRoutes() with no routers map is a no-op and does not trigger it. A single client router is enough; no ssr router, no httpMethods, no API routes involved.
| plugin version |
buildInputs: "client" |
entry css linked |
| 3.0.0-next.39 |
yes |
yes |
| 3.0.0-next.39 |
no |
yes |
| 3.0.0-next.40 |
yes |
no |
| 3.0.0-next.40 |
no |
yes |
All four verified on cold builds (rm -rf dist node_modules/.vite).
Notes
The difference buildInputs makes in the manifest is that every route module is marked isEntry (34 of them in my real app) rather than just the client entry. The chunk and its manifest record are correct either way, so it looks like the entry's CSS stops being associated with the entry once route modules become build inputs alongside it.
Only tested in SSR mode (solid({ start: true, ssr: true })). I have not checked whether client mode is affected.
Versions
@solidjs/vite-plugin 3.0.0-next.40, solid-js 2.0.0-rc.7, @solidjs/web 2.0.0-rc.7, @solidjs/router 2.0.0-next.21, filesystem-routing 0.3.0, vite 8.2.2, node 22.22
Summary
With
fileRoutes()fromfilesystem-routing/viteconfigured with aroutersmap andbuildInputs, the client entry's CSS chunk is built and recorded in the Vite manifest, but no<link rel="stylesheet">for it is emitted into the rendered head. Global styles imported by the root component never load.CSS modules imported by route components are unaffected, so the page comes back partially styled and the build succeeds with no warning or error.
Works on
3.0.0-next.39, broken on3.0.0-next.40, same source.Reproduction
minimal repro
check.mjscallshandleRequestonce against the built server bundle and reports what was built, what the manifest records, and what the head links.On
3.0.0-next.40:Expected, and what
3.0.0-next.39produces from the same source:Trigger
Both parts are needed.
buildInputson a barefileRoutes()with noroutersmap is a no-op and does not trigger it. A singleclientrouter is enough; nossrrouter, nohttpMethods, no API routes involved.buildInputs: "client"All four verified on cold builds (
rm -rf dist node_modules/.vite).Notes
The difference
buildInputsmakes in the manifest is that every route module is markedisEntry(34 of them in my real app) rather than just the client entry. The chunk and its manifest record are correct either way, so it looks like the entry's CSS stops being associated with the entry once route modules become build inputs alongside it.Only tested in SSR mode (
solid({ start: true, ssr: true })). I have not checked whether client mode is affected.Versions
@solidjs/vite-plugin 3.0.0-next.40, solid-js 2.0.0-rc.7, @solidjs/web 2.0.0-rc.7, @solidjs/router 2.0.0-next.21, filesystem-routing 0.3.0, vite 8.2.2, node 22.22