npm - @solidjs/vite-plugin - Versions diffs - 3.0.0-next.30 → 3.0.0-next.32 - Mend

@solidjs/vite-plugin 3.0.0-next.30 → 3.0.0-next.32

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.

Files changed (10) hide show

package/README.md +77 -10
package/dist/cjs/index.cjs +269 -119
package/dist/cjs/index.cjs.map +1 -1
package/dist/esm/index.mjs +269 -119
package/dist/esm/index.mjs.map +1 -1
package/dist/types/src/dev-manifest.d.ts +4 -3
package/dist/types/src/devtools/index.d.ts +3 -0
package/dist/types/src/environment.d.ts +5 -1
package/dist/types/src/ssr/index.d.ts +42 -1
package/package.json +13 -5

package/README.md CHANGED Viewed

@@ -27,13 +27,13 @@ Join [solid discord](https://discord.com/invite/solidjs) and check the [troubles
 ## Requirements
-This module is 100% ESM compatible and requires NodeJS `14.18.0` or later.
+This module is 100% ESM compatible and requires Node.js `^20.19.0 || >=22.12.0`.
-You can check your current version of NodeJS by typing `node -v` in your terminal. If your version is below that one version I'd encourage you to either do an update globally or use a NodeJS version management tool such as [Volta](https://volta.sh/) or [nvm](https://github.com/nvm-sh/nvm).
+You can check your current Node.js version by running `node -v`. Use a version
+manager such as [Volta](https://volta.sh/) or [nvm](https://github.com/nvm-sh/nvm)
+to update it.
-Supported Vite versions: **Vite 6, 7 and 8**. Support for Vite 3–5 was
-dropped; if you are on an older Vite, stay on an earlier release of this
-plugin (2.x) or upgrade Vite.
+Supported Vite versions: **Vite 8 and 9**.
 ## Quickstart
@@ -179,7 +179,37 @@ same server functions.
 The object form carries the options (`start: true` is pure sugar for
 `start: {}` — both mean the identical start mode with defaults, and
 `false`/absent means off): `app`, `document`, `entryServer`, `entryClient`,
-`middleware`, `env`, `external`, all documented below.
+`middleware`, `setup`, `env`, `devtools`, `errorBoundary`, `css`, `external`,
+all documented below.
+Install `@solidjs/start-devtools` as a development dependency to add the
+development toolbar with runtime errors and server function calls:
+```sh
+pnpm add -D @solidjs/start-devtools@next
+```
+Start mode detects the package automatically. Set `start: { devtools: true }`
+to require it or `start: { devtools: false }` to disable automatic integration.
+The package is an optional peer and the toolbar is not included in production
+builds.
+Generated entries wrap the app automatically. With custom server and client
+entries, place the development boundary around the app in the shared document
+or root:
+```tsx
+import { DevToolbar } from "@solidjs/start-devtools";
+<body>
+  <DevToolbar>
+    <App />
+  </DevToolbar>
+</body>;
+```
+The package becomes a children-only passthrough in production, so no toolbar
+code is included in either production bundle.
 ```tsx
 // src/App.tsx — the entire app: a plain content component
@@ -200,7 +230,7 @@ With `ssr: true` — **SSR start mode**:
   classic `vite build` + `vite build --ssr` two-step, work too.)
 - **Build ordering**: server builds read the client manifest, so with `ssr`
   enabled the plugin also orders builder-mode (environments API) app builds
-  client-first via a `buildApp` hook (Vite 7.1+). That covers composed
+  client-first via a `buildApp` hook. That covers composed
   setups whose own orchestrator builds server environments before the
   client — e.g. @cloudflare/vite-plugin — with no hand-written ordering
   plugin; setups without another orchestrator keep Vite's stock
@@ -429,6 +459,43 @@ client values, the leak scan — follows
 design-correct prior art, reimplemented on this plugin's machinery with
 Standard Schema as the only contract (and runtime-read server values).
+**`errorBoundary`** — in a production build, generated entries wrap the app
+in a default error boundary (and the document in an outer one): a render
+error streams a generic `500 | Internal Server Error` fallback — no stack
+or error details reach the HTML; the error itself goes to `console.error`
+— and an error caught before the shell flushes commits a real 500 status
+through the response-head lifecycle. Development is unaffected (Vite's
+error overlay owns dev errors), as are authored entries — the boundary is
+generated-entry codegen. Disable it with `start: { errorBoundary: false }`
+when application middleware owns error handling (an error middleware only
+sees the throw when no boundary catches it first). Default: `true`.
+**`css.filter`** — include/exclude patterns
+([picomatch](https://github.com/micromatch/picomatch) globs or regexes;
+relative globs resolve against the Vite root) for the module graphs the dev
+server crawls when collecting the CSS it inlines into `<head>` (the no-FOUC
+guarantee). By default the crawl covers the app's own sources and skips
+`node_modules`. `exclude` prunes matching graphs — providing one replaces
+the default `node_modules` exclusion — and `include` opts matching files in
+on top of that baseline, which is how a dependency's CSS gets
+server-inlined in dev:
+```ts
+solid({
+  start: {
+    css: { filter: { include: /node_modules\/some-ui-lib/ } },
+  },
+  ssr: true,
+});
+```
+CSS files themselves and virtual modules always pass — the filter decides
+which module graphs are traversed, not which stylesheets are kept — and a
+file matching both patterns stays excluded (Vite `createFilter`'s
+conflict rule). Development only: excluding a graph does not remove its
+CSS from the production build, where CSS always comes from the built
+assets.
 **Entry resolution** (all paths relative to the Vite root):
 1. Explicit `start.entryServer` / `start.entryClient` options.
@@ -529,7 +596,7 @@ the plugin strips its script from the served shell — nothing hydrates, so
 a shared `Document` costs nothing — and the built-in shell omits it.)
 Start-mode serving is opt-in via `start`, so bare `ssr: true` setups keep the
-transform-only behavior. See `examples/turnkey` for a complete SSR app
+transform-only behavior. See `examples/start-ssr` for a complete SSR app
 (including a one-file production server and server functions),
 `examples/start-client` for client mode (whose test flips the same app
 between the modes), and `examples/ssr` for the manual `ssr: true` wiring.
@@ -590,7 +657,7 @@ plugin's own runtime configuration.
 Meta-frameworks that need to control plugin ordering and dispatch requests
 through their own server should use the standalone `serverFunctions()`
 export instead, which never installs the dev middleware. See
-`examples/turnkey` for a complete app.
+`examples/start-ssr` for a complete app.
 **Server components (experimental):** `serverFunctions: { components: true }`
 lets a `"use server"` function return a component. Server components ride
@@ -605,7 +672,7 @@ SSR'd document and are adopted
 at boot with zero endpoint requests. With authored entries, the app-side
 pieces (the render plugin, the bootstrap script, and the client's
 `installServerComponents()` call, all from `@solidjs/web/frames`) live in
-your entry files instead. See `examples/turnkey` for a complete page.
+your entry files instead. See `examples/start-ssr` for a complete page.
 #### options.compiler