Version Packages (next)

[github-actions]

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.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 (<Loading> only shows fallback in SSR 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; stream mode is unchanged. Requires solid-js / @solidjs/web ^2.0.0-rc.7, which freezes the response head when the awaited render completes so httpStatus / httpHeader declarations reach the response (fix(web): freeze response head before disposing an awaited renderToStream solid#3292).

Patch Changes

• a810d09: Dev servers now inline solid-js and @solidjs/web into every server environment instead of externalizing them. resolve.externalConditions only governs the imports Vite's module runner resolves itself; an externalized package's own imports are resolved by Node with Node's conditions, never development. Since solid 2.0.0-rc.7 both core packages ship a dist/server.dev.* behind that condition, so under vite dev the framework split in two: the app's solid-js was the runner's dev copy while @solidjs/web's import "solid-js" landed on Node's production copy. renderToStream installed the asset resolver on one sharedConfig and lazy() read the other — every dev SSR page with a lazy() component failed with lazy() called with moduleUrl "…" but no asset manifest is set — and every other module-level singleton (owner tracking, request events, hydration keys) was divided the same way. With the two packages in resolve.noExternal every resolution, theirs included, goes through the environment's conditions and a single dev build is loaded end to end. Applies whenever the plugin injects dev mode into a server environment; vitest projects (which manage their own inlining) and hosts that set noExternal: true are left as they are.

• a3cc782: Fix vite dev breaking after a mid-session dependency re-optimization when the development toolbar is installed. The generated entries' @solidjs/start-devtools import reused the id captured when the toolbar was detected; in the client environment that id is the optimizer's pre-bundled URL, stamped with the browserHash of the pass that produced it. Any dependency discovered after the initial scan re-optimizes — the toolbar's chunks are re-emitted under new names and the hash moves on — and the frozen id kept the entry on the previous pass: its lazy chunks answered 504 Outdated Optimize Dep and the stale bundle brought a second solid-js instance into the page (hydration key misses, REACTIVITY_HALTED). The import is now resolved afresh on every request, so it always follows the current optimizer pass.

  The most common trigger is also removed: the agent diagnostics bridge (@solidjs/diagnostics/browser and /protocol) reaches the page through a virtual module the dependency scanner never crawls, so its first load discovered the two imports and forced exactly that re-optimize + reload. The diagnostics plugin now pre-bundles them up front whenever the surface is enabled.

• c16985a: Provide the deployment secret to server builds (The flash cookie carries the submission with no SameSite, no lifetime and no __Host- prefix solid#3239): the generated server-function handler module now leads with globalThis.__SOLID_SECRET__ ??= "<random-per-build>", giving the runtime's encrypted no-JS flash cookie a key with zero configuration. One value is generated per plugin instance, so a production build bakes a single secret into the emitted server chunk (shared by every instance of that deployment) and a dev session holds one for its lifetime. Server output only — the handler module is already hard-gated against client graphs — and an explicit configureServerFunctionsServer({ secret }) still outranks it.

• 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.