solid-vite-plugin

Problem The plugin-managed application mode can compose with provider Vite plugins, but the deployment-facing contract is currently spread across generated virtual modules, environment setup, build ordering, output directories, manifests, static output, and prerender behavior. Provider integrations should not need to depend on undocumented implementation details to deploy a Solid application. Proposed scope Document and test the portable contract between and deployment adapters: the production server service entry and Fetch handler shape client and server environment names and required build ordering client assets, manifests, and output locations SSR, client-only, and server-function-only output differences static shell and prerender output which lifecycle steps the Solid plugin owns which responsibilities remain with provider plugins Where appropriate, expose named APIs or types instead of requiring adapters to import private virtual modules or reproduce internal assumptions. Non-goals implementing provider-specific deployment policy replacing Cloudflare, Netlify, Nitro, or other Vite integrations prescribing platform configuration The goal is a stable composition boundary so provider plugins can remain thin adapters over a web-standard Solid application handler.

Summary Renames the plugin-managed option to Renames to Uses for the root component Groups explicit rendering entries under and Renames to Moves typed env configuration from to the top-level option Updates internal plugin names, documentation, and example directories Keeps top-level Why describes the optional layer where the plugin owns entries, rendering, dev serving, and build orchestration. It avoids tying that capability to the retired SolidStart name. and remain independent capabilities. They can be used by router integrations, manual SSR setups, and other projects without plugin-managed application rendering. JavaScript configs using or receive migration errors. No compatibility aliases are retained before the stable release. Testing app client suite: 46/46 env suite: 48/48 app SSR suite: 366/366 HTTP bridge suite: 10/10

Background I got on Solid 2 migration bundling with tsdown. Solution The / boundary guard no longer crashes when isn't available on resolve hooks, and now detects the target environment through the same helper used by the rest of the plugin, falling back to the resolve hook's flag when the environment is absent.