@solidjs/vite-plugin 3.0.0-next.27

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.
@@ -0,0 +1,162 @@
1
+ import { type Plugin } from 'vite';
2
+ /**
3
+ * Options for the main plugin's `start` option (`start: true` is
4
+ * sugar for the empty bag). One bag serves both modes — the plugin's `ssr`
5
+ * boolean picks between them, so flipping a project between
6
+ * client-rendered and server-rendered is toggling that boolean, never
7
+ * reshaping this object. Server-only options (`entryServer`, `external`)
8
+ * are documented no-ops in client mode: they stay in the config across a
9
+ * flip instead of erroring.
10
+ */
11
+ export interface StartOptions {
12
+ /**
13
+ * Root component module for generated entries (the zero-config path).
14
+ * Resolved relative to the Vite root.
15
+ *
16
+ * @default "src/App.{tsx,jsx,ts,js}" (also probes lowercase "src/app.*")
17
+ */
18
+ app?: string;
19
+ /**
20
+ * Server entry module. Must export `render(request?, context?)` returning
21
+ * a `renderToStream` result, an HTML string, or a `Response`.
22
+ * `context.clientEntry` carries the resolved client entry URL.
23
+ *
24
+ * Server mode only — ignored in client mode, where the server entry is
25
+ * always generated (it renders the document shell without the app, for
26
+ * dev serving and the build-time prerender). Conventional
27
+ * `src/entry-server.*` files are likewise ignored there.
28
+ *
29
+ * @default "src/entry-server.{tsx,jsx,ts,js,mjs}" when present, else a
30
+ * generated entry rendering `<Document><App /></Document>`
31
+ */
32
+ entryServer?: string;
33
+ /**
34
+ * Client entry module. In SSR mode it hydrates; in client mode it mounts
35
+ * (a generated one calls `render()`), and it stands alone — no pairing
36
+ * rule with a server entry.
37
+ *
38
+ * @default "src/entry-client.{tsx,jsx,ts,js,mjs}" when present, else a
39
+ * generated entry
40
+ */
41
+ entryClient?: string;
42
+ /**
43
+ * Document shell component wrapping the app in generated entries. Receives
44
+ * `props.children` and must render the full `<html>` document including
45
+ * `<HydrationScript />` (in client mode, where nothing hydrates, the
46
+ * handler strips its output from the served/prerendered shell — a shared
47
+ * Document costs nothing across the flip; the built-in shell omits it per
48
+ * mode). Only used when the server entry is generated.
49
+ *
50
+ * @default "src/Document.{tsx,jsx}" when present, else a built-in shell
51
+ */
52
+ document?: string;
53
+ /**
54
+ * Path to a server-only module (resolved relative to the Vite root) whose
55
+ * default export is one fetch-style middleware function — `(request,
56
+ * next) => Response | Promise<Response>` — or an array of them, composed
57
+ * in order. The chain fronts every request the plugin dispatches — page
58
+ * SSR, the server-function endpoint, dev and production, `vite preview` —
59
+ * and runs inside the request-event scope, so `getRequestEvent()` works
60
+ * exactly as it does in application code (decorate `locals`, write the
61
+ * `response` stub). `next()` advances the chain (pass a `Request` to
62
+ * substitute it downstream); nothing reaches the wire until the outermost
63
+ * middleware returns, so headers on the returned `Response` stay mutable
64
+ * after `next()` — streamed bodies included — and error middleware is a
65
+ * plain `try { return await next(); } catch { ... }`.
66
+ *
67
+ * All methods and accept types dispatch through the chain — API routes
68
+ * and no-JS form POSTs included, in dev exactly as in production. A
69
+ * non-page request (anything but an HTML-accepting GET) that no
70
+ * middleware handled falls back to Vite's own pipeline in dev instead of
71
+ * rendering the page at it.
72
+ *
73
+ * @default undefined
74
+ */
75
+ middleware?: string;
76
+ /**
77
+ * Path to a server-only module (resolved relative to the Vite root) whose
78
+ * default export runs once per request in the generated server entry,
79
+ * after the middleware chain has dispatched to the page render and
80
+ * immediately before `renderToStream`: `(event, App) => Component | void |
81
+ * Promise<Component | void>`. The per-request seam for routers that must
82
+ * prepare an app instance before SSR begins (create a router bound to the
83
+ * request, `await router.load()`, then render): return a component and the
84
+ * generated entry renders it in the app's place inside the Document;
85
+ * return nothing and `<App />` renders unchanged. `event` is the shared
86
+ * request event — the same one the middleware chain decorated (`locals`
87
+ * are visible) — and the hook runs inside the request scope, so
88
+ * `getRequestEvent()` answers in anything it calls.
89
+ *
90
+ * Only meaningful with generated entries: an authored `entry-server`
91
+ * already owns its render function, so configuring both is an error.
92
+ * Server mode only — ignored in client mode (there is no per-request app
93
+ * render to prepare), so the config survives the `ssr` boolean flip.
94
+ *
95
+ * @default undefined
96
+ */
97
+ setup?: string;
98
+ /**
99
+ * Typed, validated environment variables. A schema file — conventionally
100
+ * `env.ts` (or `env.js`) at the project root, probed automatically —
101
+ * default-exports `{ server?, client? }` maps of Standard Schema
102
+ * validators (zod, valibot, arktype, mixable per key), and the plugin
103
+ * exposes the validated values through `virtual:env/server` (all vars,
104
+ * server module graphs only — a client-graph import is a hard error) and
105
+ * `virtual:env/client` (the `VITE_`-prefixed `client` side; the prefix is
106
+ * enforced at config time). Validation runs at config/build time in node
107
+ * only against Vite's `loadEnv` merge of the `.env*` files (with
108
+ * `process.env` winning), which the plugin also folds into `process.env`
109
+ * itself — no `loadEnv` boilerplate in vite.config. Failures fail the
110
+ * build / render the dev error overlay with the per-key report, and a
111
+ * `solid-env.d.ts` is generated next to the schema so both virtual
112
+ * modules are fully typed by inference.
113
+ *
114
+ * Client values are baked as plain JSON (that's what `VITE_` means); no
115
+ * validator ships in a client bundle, and a client-build leak scan
116
+ * errors when a server value shows up in a client chunk. Server values
117
+ * are NOT baked: `virtual:env/server` reads `process.env` at server boot
118
+ * and validates through your schema (imported into the server bundle
119
+ * only), so platform-injected vars work and secrets rotate without a
120
+ * rebuild — no secret exists in any dist artifact. Build-time server
121
+ * failures are a deferred-to-boot warning; dev failures stay hard.
122
+ *
123
+ * `true` requires the conventional file (error when missing); a string
124
+ * is an explicit schema path; `false` disables even the probing.
125
+ * Env is a start-mode feature: without `start` there is no env layer.
126
+ *
127
+ * @default undefined (probe env.ts / env.js; off when absent)
128
+ */
129
+ env?: boolean | string;
130
+ /**
131
+ * Let a host integration own the server environment — build wiring and
132
+ * HTTP serving alike. The plugin skips its start-mode server-build config and
133
+ * stands its dev middlewares down (SSR serving and the server-function
134
+ * endpoint); the generated `virtual:solid-ssr-handler` self-serves
135
+ * instead, inlining dev styles through a virtual module and composing the
136
+ * server-function endpoint. Its named `handleRequest(request)` and default
137
+ * Fetchable exports provide the same contract in dev and production.
138
+ * Generated entries and the client manifest are still provided.
139
+ *
140
+ * Often unnecessary: a provider-owned (non-runnable) `ssr` dev environment
141
+ * is detected automatically and the middlewares stand down on their own;
142
+ * the normal `ssr` environment also exposes the handler as an `index`
143
+ * service entry for provider build orchestrators. Set this only when the
144
+ * host does not adopt that environment — for example, when it uses a
145
+ * different name or independently configures the server build. To hand
146
+ * over only the server-function endpoint, use
147
+ * `serverFunctions.devMiddleware: false` instead.
148
+ *
149
+ * Server mode only — ignored in client mode (there is no server side to
150
+ * hand over; the shell prerender and, with `serverFunctions`, the
151
+ * endpoint handler are the whole story).
152
+ *
153
+ * @default false
154
+ */
155
+ external?: boolean;
156
+ }
157
+ export declare const SSR_HANDLER_ID = "virtual:solid-ssr-handler";
158
+ export declare function startServe(options: StartOptions, internal?: {
159
+ serverFunctions?: boolean;
160
+ serverComponents?: boolean;
161
+ ssr?: boolean;
162
+ }): Plugin[];
@@ -0,0 +1,10 @@
1
+ import { type Plugin } from 'vite';
2
+ export declare const CLIENT_ENV_ID = "virtual:env/client";
3
+ export declare const SERVER_ENV_ID = "virtual:env/server";
4
+ /**
5
+ * Start-mode typed env (the `start.env` option). Returns no plugin when the
6
+ * feature is off (`env: false`, or nothing to probe); the feature is
7
+ * start-only by construction — the option lives on `start`, so a bare
8
+ * `ssr: true` setup has no env layer (documented).
9
+ */
10
+ export declare function startEnv(option: boolean | string | undefined): Plugin[];
package/package.json ADDED
@@ -0,0 +1,98 @@
1
+ {
2
+ "name": "@solidjs/vite-plugin",
3
+ "version": "3.0.0-next.27",
4
+ "description": "solid-js integration plugin for vite 6/7/8",
5
+ "type": "module",
6
+ "files": [
7
+ "dist",
8
+ "virtual-solid-manifest.d.ts",
9
+ "boundary-modules.d.ts"
10
+ ],
11
+ "main": "dist/cjs/index.cjs",
12
+ "module": "dist/esm/index.mjs",
13
+ "types": "dist/types/src/index.d.ts",
14
+ "exports": {
15
+ ".": {
16
+ "types": "./dist/types/src/index.d.ts",
17
+ "import": "./dist/esm/index.mjs",
18
+ "node": "./dist/cjs/index.cjs",
19
+ "require": "./dist/cjs/index.cjs",
20
+ "default": "./dist/cjs/index.cjs"
21
+ },
22
+ "./virtual-solid-manifest": {
23
+ "types": "./virtual-solid-manifest.d.ts"
24
+ },
25
+ "./boundary-modules": {
26
+ "types": "./boundary-modules.d.ts"
27
+ }
28
+ },
29
+ "scripts": {
30
+ "build": "rollup -c && tsc --emitDeclarationOnly",
31
+ "dev": "rollup -c -w",
32
+ "prepublishOnly": "pnpm build",
33
+ "release": "pnpm build && changeset publish",
34
+ "check": "package-check",
35
+ "test": "node scripts/test-examples.ts"
36
+ },
37
+ "repository": {
38
+ "type": "git",
39
+ "url": "git+https://github.com/solidjs/solid-vite-plugin.git"
40
+ },
41
+ "keywords": [
42
+ "vite",
43
+ "vite plugin",
44
+ "vitejs",
45
+ "vitejs plugin",
46
+ "vite-plugin",
47
+ "solid"
48
+ ],
49
+ "author": "Alexandre Mouton-Brady <amoutonbrady@gmail.com>",
50
+ "license": "MIT",
51
+ "publishConfig": {
52
+ "access": "public"
53
+ },
54
+ "bugs": {
55
+ "url": "https://github.com/solidjs/solid-vite-plugin/issues"
56
+ },
57
+ "homepage": "https://github.com/solidjs/solid-vite-plugin#readme",
58
+ "dependencies": {
59
+ "@ampproject/remapping": "^2.3.0",
60
+ "@babel/core": "^7.23.3",
61
+ "@dom-expressions/compiler": "0.50.0-next.40",
62
+ "@types/babel__core": "^7.20.4",
63
+ "babel-preset-solid": ">=2.0.0-beta.32 <2.0.0-experimental.0",
64
+ "merge-anything": "^5.1.7",
65
+ "vitefu": "^1.0.4"
66
+ },
67
+ "devDependencies": {
68
+ "@babel/preset-env": "^7.23.3",
69
+ "@babel/preset-typescript": "^7.23.3",
70
+ "@changesets/cli": "^2.30.0",
71
+ "@rollup/plugin-babel": "^6.0.4",
72
+ "@rollup/plugin-commonjs": "^25.0.7",
73
+ "@rollup/plugin-node-resolve": "^15.2.3",
74
+ "@skypack/package-check": "^0.2.2",
75
+ "@types/node": "^18.18.4",
76
+ "cypress": "^14.0.0",
77
+ "cypress-visual-regression": "^5.2.2",
78
+ "cypress-vite": "^1.6.0",
79
+ "cypress-wait-until": "^3.0.2",
80
+ "prettier": "^3.1.0",
81
+ "rollup": "^4.5.0",
82
+ "rollup-plugin-cleaner": "^1.0.0",
83
+ "solid-js": ">=2.0.0-beta.32 <2.0.0-experimental.0",
84
+ "typescript": "^5.2.2",
85
+ "vite": "^7.0.0"
86
+ },
87
+ "peerDependencies": {
88
+ "@solidjs/web": ">=2.0.0-beta.32 <2.0.0-experimental.0",
89
+ "@testing-library/jest-dom": "^5.16.6 || ^5.17.0 || ^6.*",
90
+ "solid-js": ">=2.0.0-beta.32 <2.0.0-experimental.0",
91
+ "vite": "^6.0.0 || ^7.0.0 || ^8.0.0"
92
+ },
93
+ "peerDependenciesMeta": {
94
+ "@testing-library/jest-dom": {
95
+ "optional": true
96
+ }
97
+ }
98
+ }
@@ -0,0 +1,52 @@
1
+ declare module "virtual:solid-manifest" {
2
+ import type { ViteManifest } from "@solidjs/vite-plugin";
3
+ const manifest: ViteManifest;
4
+ export default manifest;
5
+ }
6
+
7
+ // Side-effect module: importing it loads every module containing server
8
+ // functions so their registrations exist before requests are dispatched.
9
+ declare module "virtual:solid-server-function-manifest" {}
10
+
11
+ // Server-only handler (SSR builds). Importing it registers every
12
+ // server function (via the manifest above), scopes each request with
13
+ // provideRequestEvent, and configures the endpoint; mount
14
+ // `handleServerFunctionRequest` on the endpoint in your server.
15
+ declare module "virtual:solid-server-function-handler" {
16
+ /** The resolved endpoint path (plugin `endpoint` option joined with Vite `base`). */
17
+ export const endpoint: string;
18
+ export function handleServerFunctionRequest(
19
+ request: Request,
20
+ options?: Record<string, unknown>,
21
+ ): Promise<Response>;
22
+ }
23
+
24
+ // Server-only start-mode request handler (the `start` option). It is the SSR
25
+ // build's entry, so a production server imports it from the built bundle
26
+ // (e.g. `./dist/server/server.js`) rather than by this id; importing the
27
+ // id directly also works from custom server code in SSR builds.
28
+ // Streams the rendered app for a web Request, scopes it with
29
+ // provideRequestEvent, resolves hashed client assets through the build
30
+ // manifest, and — when `serverFunctions` is enabled — serves the
31
+ // server-function endpoint ahead of SSR.
32
+ declare module "virtual:solid-ssr-handler" {
33
+ export function handleRequest(
34
+ request: Request,
35
+ options?: {
36
+ /** Override the resolved client entry URL injected into the document. */
37
+ clientEntry?: string;
38
+ /** Extra fields merged into the `context` passed to the entry's `render`. */
39
+ context?: Record<string, unknown>;
40
+ /** Status/headers for the HTML response. */
41
+ responseInit?: ResponseInit;
42
+ /** Options forwarded to the server-function handler for endpoint requests. */
43
+ serverFunctions?: Record<string, unknown>;
44
+ },
45
+ ): Promise<Response>;
46
+
47
+ /** Fetchable entry for runtimes and deployment integrations that use the web-standard convention. */
48
+ const handler: {
49
+ fetch(request: Request): Promise<Response>;
50
+ };
51
+ export default handler;
52
+ }