You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Entry CSS <link> not emitted when fileRoutes uses buildInputs (regression in 3.0.0-next.40) #353
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.
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: newPageFileSystemRouter({ 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.
Fixed by #354 (virtual:solid-manifest now names the client entry explicitly via _entry instead of taking the first isEntry record, which #347 made ambiguous when fileRoutes({ buildInputs }) registers route modules as configured inputs). Shipped in @solidjs/vite-plugin@3.0.0-next.41. Closing manually since this repo merges to next, not the default branch.
Fixed by #354 and released in @solidjs/vite-plugin@3.0.0-next.41. Confirmed with your repro against the published tarball: linked in <head>: true, stylesheet links: 2, and the <script type="module"> now points at the real client entry chunk (on next.40 it booted the route chunk, so the page also never hydrated). Thanks for the precise report and repro.
Activity
Merge pull request #354 from solidjs/fix/353-manifest-entry
fix: name the client entry in virtual:solid-manifest instead of guess…
ryansolid commentedon Sep 10, 2026
Fixed by #354 (
virtual:solid-manifestnow names the client entry explicitly via_entryinstead of taking the firstisEntryrecord, which #347 made ambiguous whenfileRoutes({ buildInputs })registers route modules as configured inputs). Shipped in@solidjs/vite-plugin@3.0.0-next.41. Closing manually since this repo merges tonext, not the default branch.ryansolid commentedon Sep 10, 2026
Fixed by #354 and released in
@solidjs/vite-plugin@3.0.0-next.41. Confirmed with your repro against the published tarball:linked in <head>: true,stylesheet links: 2, and the<script type="module">now points at the real client entry chunk (on next.40 it booted the route chunk, so the page also never hydrated). Thanks for the precise report and repro.