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

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
  1. package/README.md +53 -4
  2. package/dist/cjs/index.cjs +205 -43
  3. package/dist/cjs/index.cjs.map +1 -1
  4. package/dist/esm/index.mjs +207 -45
  5. package/dist/esm/index.mjs.map +1 -1
  6. package/dist/types/src/dev-manifest.d.ts +4 -3
  7. package/dist/types/src/devtools/index.d.ts +5 -0
  8. package/dist/types/src/environment.d.ts +3 -0
  9. package/dist/types/src/ssr/index.d.ts +42 -1
  10. package/package.json +8 -3
package/README.md CHANGED
@@ -179,7 +179,19 @@ same server functions.
179
179
  The object form carries the options (`start: true` is pure sugar for
180
180
  `start: {}` — both mean the identical start mode with defaults, and
181
181
  `false`/absent means off): `app`, `document`, `entryServer`, `entryClient`,
182
- `middleware`, `env`, `external`, all documented below.
182
+ `middleware`, `setup`, `env`, `devtools`, `errorBoundary`, `css`, `external`,
183
+ all documented below.
184
+
185
+ Install `@solidjs/start-devtools` as a development dependency to add the
186
+ development toolbar with runtime errors and server function calls:
187
+
188
+ ```sh
189
+ pnpm add -D @solidjs/start-devtools@next
190
+ ```
191
+
192
+ Start mode detects the package automatically. Set `start: { devtools: true }`
193
+ to require it or `start: { devtools: false }` to disable it. The package is an
194
+ optional peer and the toolbar is not included in production builds.
183
195
 
184
196
  ```tsx
185
197
  // src/App.tsx — the entire app: a plain content component
@@ -429,6 +441,43 @@ client values, the leak scan — follows
429
441
  design-correct prior art, reimplemented on this plugin's machinery with
430
442
  Standard Schema as the only contract (and runtime-read server values).
431
443
 
444
+ **`errorBoundary`** — in a production build, generated entries wrap the app
445
+ in a default error boundary (and the document in an outer one): a render
446
+ error streams a generic `500 | Internal Server Error` fallback — no stack
447
+ or error details reach the HTML; the error itself goes to `console.error`
448
+ — and an error caught before the shell flushes commits a real 500 status
449
+ through the response-head lifecycle. Development is unaffected (Vite's
450
+ error overlay owns dev errors), as are authored entries — the boundary is
451
+ generated-entry codegen. Disable it with `start: { errorBoundary: false }`
452
+ when application middleware owns error handling (an error middleware only
453
+ sees the throw when no boundary catches it first). Default: `true`.
454
+
455
+ **`css.filter`** — include/exclude patterns
456
+ ([picomatch](https://github.com/micromatch/picomatch) globs or regexes;
457
+ relative globs resolve against the Vite root) for the module graphs the dev
458
+ server crawls when collecting the CSS it inlines into `<head>` (the no-FOUC
459
+ guarantee). By default the crawl covers the app's own sources and skips
460
+ `node_modules`. `exclude` prunes matching graphs — providing one replaces
461
+ the default `node_modules` exclusion — and `include` opts matching files in
462
+ on top of that baseline, which is how a dependency's CSS gets
463
+ server-inlined in dev:
464
+
465
+ ```ts
466
+ solid({
467
+ start: {
468
+ css: { filter: { include: /node_modules\/some-ui-lib/ } },
469
+ },
470
+ ssr: true,
471
+ });
472
+ ```
473
+
474
+ CSS files themselves and virtual modules always pass — the filter decides
475
+ which module graphs are traversed, not which stylesheets are kept — and a
476
+ file matching both patterns stays excluded (Vite `createFilter`'s
477
+ conflict rule). Development only: excluding a graph does not remove its
478
+ CSS from the production build, where CSS always comes from the built
479
+ assets.
480
+
432
481
  **Entry resolution** (all paths relative to the Vite root):
433
482
 
434
483
  1. Explicit `start.entryServer` / `start.entryClient` options.
@@ -529,7 +578,7 @@ the plugin strips its script from the served shell — nothing hydrates, so
529
578
  a shared `Document` costs nothing — and the built-in shell omits it.)
530
579
 
531
580
  Start-mode serving is opt-in via `start`, so bare `ssr: true` setups keep the
532
- transform-only behavior. See `examples/turnkey` for a complete SSR app
581
+ transform-only behavior. See `examples/start-ssr` for a complete SSR app
533
582
  (including a one-file production server and server functions),
534
583
  `examples/start-client` for client mode (whose test flips the same app
535
584
  between the modes), and `examples/ssr` for the manual `ssr: true` wiring.
@@ -590,7 +639,7 @@ plugin's own runtime configuration.
590
639
  Meta-frameworks that need to control plugin ordering and dispatch requests
591
640
  through their own server should use the standalone `serverFunctions()`
592
641
  export instead, which never installs the dev middleware. See
593
- `examples/turnkey` for a complete app.
642
+ `examples/start-ssr` for a complete app.
594
643
 
595
644
  **Server components (experimental):** `serverFunctions: { components: true }`
596
645
  lets a `"use server"` function return a component. Server components ride
@@ -605,7 +654,7 @@ SSR'd document and are adopted
605
654
  at boot with zero endpoint requests. With authored entries, the app-side
606
655
  pieces (the render plugin, the bootstrap script, and the client's
607
656
  `installServerComponents()` call, all from `@solidjs/web/frames`) live in
608
- your entry files instead. See `examples/turnkey` for a complete page.
657
+ your entry files instead. See `examples/start-ssr` for a complete page.
609
658
 
610
659
  #### options.compiler
611
660