Version Packages (next)

.changeset/pre.json

@@ -68,6 +68,7 @@
     "path-addressed-server-functions",
     "plugin-package-rename",
     "production-error-boundary",
+    "protect-configured-entry-chunks",
     "reject-prefixed-server-env-keys",
     "remove-client-manifest-virtual",
     "response-head-middleware-preview",
@@ -90,6 +91,7 @@
     "start-css-filter",
     "start-env-typed",
     "start-mode-terminology",
+    "start-render-mode",
     "start-setup-hook",
     "support-tsrx-vite",
     "true-boxes-arrive",

CHANGELOG.md

@@ -1,5 +1,15 @@
 # Changelog
 
+## 3.0.0-next.40
+
+### Minor Changes
+
+- 0985ce8: `start.renderMode: 'stream' | 'async'` (default `'stream'`), plus a per-request form and a runtime override — the fix for streaming SSR leaving `<Loading>` fallbacks unresolved for clients that never run JavaScript (solidjs/solid#3280). `'async'` makes the generated handler adopt the `renderToStream` result's thenable, which resolves with the complete HTML once every boundary has settled: nothing has flushed, so each boundary's content is spliced in place of its placeholder — no fallback markup, no swap templates or scripts — while hydration data still serializes and JavaScript clients hydrate as before. The string then takes `createSSRResponse`'s string path: the response head commits, the document gets the doctype and client-entry injection, and a `Location` written mid-render becomes a real 3xx instead of the post-flush script redirect. The tradeoffs are inherent and documented: time-to-first-byte waits for the slowest boundary and the whole page buffers in memory; `deferStream` is moot (everything defers). The per-request form follows the `middleware`/`setup` convention — `renderMode: './src/render-mode.ts'`, a module default-exporting `(event) => 'stream' | 'async' | Promise<...>` run inside the request scope after the middleware chain — for policies like "complete documents for crawler user agents or `?nojs`, streaming for everyone else". Hosts driving the handler directly pass `handleRequest(request, { renderMode })`; precedence is that runtime option, then the module function, then the static config, and an invalid value from any source is rejected with an actionable error (unknown literals and missing module paths fail at config time). Works identically for authored entries. Generated entries also commit the response head at render completion (`onCompleteAll`) so `httpStatus`/`httpHeader` declarations survive the runtime's dispose-before-resolve in the awaited path; stream mode is unchanged.
+
+### Patch Changes
+
+- 1f5f6ca: Never strip `isEntry` from a genuine configured entry when reclassifying emitted lazy facade chunks. The normalization used to demote every chunk that is a dynamic-import target, which misfires once the real client entry absorbs a module that is also imported dynamically: with Solid 2, `@solidjs/web/frames/client` lazily imports the serialization decoder, so a static import of `@solidjs/web/serialization/decode` anywhere in the client graph merges the decoder into the entry chunk and the entry ends up listing itself under `dynamicImports`. Demoting it left the bundle and `manifest.json` with no entry at all ("No entry file found" in downstream manifest capture such as TanStack Start's). Chunks whose facade matches a configured `build.rollupOptions.input` (or the default `index.html` / the start-mode client entry) now keep `isEntry` in the raw bundle and in `virtual:solid-manifest`, a chunk's dynamic import of itself is ignored, emitted `lazy()` facades are still reclassified, and a demotion the plugin cannot attribute to one of its own emitted chunks is reported with a warning describing the graph shape. The virtual manifest also repairs `isDynamicEntry` on lazy facades, which rolldown drops when syncing `generateBundle` mutations back.
+
 ## 3.0.0-next.39
 
 ### Patch Changes

package.json

@@ -1,6 +1,6 @@
 {
   "name": "@solidjs/vite-plugin",
-  "version": "3.0.0-next.39",
+  "version": "3.0.0-next.40",
   "description": "solid-js integration plugin for Vite",
   "type": "module",
   "engines": {