@solidjs/vite-plugin 3.0.0-next.27

package/dist/types/src/boundary-modules.d.ts

@@ -0,0 +1,18 @@
+import type { Plugin } from 'vite';
+/**
+ * `server-only` and `client-only` marker modules: importing `server-only`
+ * from a module bundled for the client fails the build at resolve time with
+ * a descriptive error (and vice versa for `client-only`); in the allowed
+ * environment the marker resolves to an empty module.
+ *
+ * Server-only code pulled into a client bundle otherwise ships silently and
+ * crashes at runtime (in hydrating apps, typically as a cryptic hydration
+ * failure far from the real cause) — the marker turns that into a build
+ * error naming the importer.
+ *
+ * Always on (`enforce: 'pre'`), so the bare specifiers are claimed by this
+ * plugin even when React's `server-only`/`client-only` npm packages are
+ * installed — the environment semantics are the same, and claiming them
+ * keeps the behavior deterministic and the errors identifiable as ours.
+ */
+export declare function boundaryModules(): Plugin;

package/dist/types/src/dev-manifest.d.ts

@@ -0,0 +1,128 @@
+import type { DevEnvironment, ViteDevServer } from 'vite';
+/**
+ * Dev-mode asset resolution: the `virtual:solid-manifest` module exports a
+ * resolver function in dev (instead of the static object a build produces),
+ * and the runtime installs it as `context.resolveAssets` verbatim. When
+ * server-side `lazy()` resolves a module key, the resolver walks the SSR
+ * environment's live module graph collecting transitively imported CSS and
+ * answers with inline-style descriptors — SSR'd `<style data-vite-dev-id>`
+ * tags that Vite's HMR client adopts on startup, so dev CSS is styled from
+ * the first streamed byte without fighting Vite's own style injection.
+ *
+ * The walk design follows SolidStart's collect-styles (by @katywings): crawl
+ * `transformResult.deps` on the SSR environment (the client environment's
+ * transform results don't list CSS deps), skipping dynamic imports since
+ * dynamically imported modules register their own styles when they render.
+ */
+export type DevStyleDescriptor = {
+    id: string;
+    content: string;
+    attrs?: Record<string, string>;
+};
+export type DevStyleSource = {
+    id: string;
+    url: string;
+};
+export type ResolvedAssets = {
+    js: string[];
+    css: (string | DevStyleDescriptor)[];
+};
+export type DevAssetResolver = {
+    /**
+     * Answers synchronously (a plain object) once the key's assets are known.
+     * The sync answer is load-bearing for SSR convergence: the runtime retries
+     * a suspended render pass by re-creating the lazy component, which
+     * re-requests its assets — if every answer is a fresh pending promise the
+     * pass suspends again on a promise that did not exist when the retry
+     * began, and never converges (see `createDevAssetResolver`).
+     */
+    resolve: (key: string) => ResolvedAssets | null | Promise<ResolvedAssets | null>;
+    /**
+     * Synchronous fast path used by sync consumers (a lazy component's
+     * `moduleUrl` getter for islands): the module's dev URL is knowable
+     * without the async CSS graph walk.
+     */
+    resolveSync: (key: string) => ResolvedAssets;
+};
+export declare const DEV_MANIFEST_REGISTRY_KEY = "@solidjs/vite-plugin:dev-manifest";
+export declare function registerDevAssetResolver(root: string, resolver: DevAssetResolver): void;
+/**
+ * HTTP bridge endpoint for isolated SSR runners. Hosts that evaluate server
+ * modules outside the Vite process (nitro's dev worker, workerd via
+ * @cloudflare/vite-plugin) can't see the `globalThis` registry, so the dev
+ * server itself serves asset resolution: `GET
+ * /@solidjs/vite-plugin/dev-manifest?key=<module key>` answers with the
+ * resolver's `ResolvedAssets` JSON (`null` when the key can't be resolved).
+ * The dev flavor of `virtual:solid-manifest` falls back to fetching it when
+ * the registry has no entry for the root — in-process consumers hit the
+ * registry and never touch HTTP.
+ */
+export declare const DEV_MANIFEST_ENDPOINT = "/@solidjs/vite-plugin/dev-manifest";
+export declare function installDevManifestBridge(server: ViteDevServer): void;
+/**
+ * The absolute URL isolated runners should fetch the bridge from, baked into
+ * the dev flavor of `virtual:solid-manifest` when its code is generated.
+ * Generation happens while serving an SSR request, so the server is already
+ * listening and `resolvedUrls` carries the real origin (a config-time define
+ * could only guess the port). Middleware-mode servers have no origin of
+ * their own to advertise — returns null there, and the manifest module keeps
+ * the js-only fallback (in-process registry hits are unaffected either way).
+ */
+export declare function devManifestBridgeUrl(server: ViteDevServer): string | null;
+/**
+ * Inline dev script reconciling SSR'd style tags with Vite's HMR client.
+ * Frameworks that server-render whole documents should inline this in dev,
+ * in `<head>` before any module script. It does two things, via a
+ * MutationObserver so styles appended by streamed boundaries are handled as
+ * they arrive (Vite's client seeds its stylesheet registry from the DOM only
+ * once, when its module evaluates):
+ *
+ * - Rewrites serialized virtual-module ids (`/@id/__x00__…`) back to Vite's
+ *   null-byte form so seeding matches (a raw `\0` can't survive HTML).
+ * - Dedupes twins: a style tag that streams in after Vite's client has
+ *   seeded is missed by the scan, so the CSS module injects its own copy
+ *   client-side. Whenever two style tags share a `data-vite-dev-id`, the
+ *   SSR'd one (marked `data-asset`) is removed in favor of the Vite-owned
+ *   one, which is the tag HMR updates.
+ *
+ * Observation is two-phase to stay cheap: a document-wide subtree observer
+ * only for the streaming window (SSR tags can only arrive while the parser
+ * is consuming the stream; DOMContentLoaded marks its end), then a
+ * childList-only observer on `document.head` for the page lifetime — Vite
+ * injects twins into the head during hydration, which continues past
+ * DOMContentLoaded, and a non-subtree head observer never fires on app DOM
+ * churn, only on head insertions.
+ *
+ * Descends from SolidStart's PatchVirtualDevStyles (by @katywings); this
+ * belongs in Vite itself eventually.
+ */
+export declare const devStylePatch: string;
+/** Discovers ambient CSS in an entry graph without choosing how it is transported. */
+export declare function collectDevStyleSources(env: DevEnvironment, files: string[], onFile?: (file: string) => void): Promise<DevStyleSource[]>;
+/**
+ * Walks the SSR module graph from `files` (root-relative or absolute) and
+ * returns inline-style descriptors for every transitively imported CSS
+ * module — the same shape the dev asset resolver answers with for lazy
+ * modules. Used by SSR start mode's dev middleware to inline the root entry's
+ * CSS into `<head>` so server-painted content is styled from the first byte
+ * (no FOUC while waiting for Vite's client-side style injection).
+ */
+export declare function collectDevStyles(server: ViteDevServer, files: string[]): Promise<DevStyleDescriptor[]>;
+/**
+ * Serializes a dev style descriptor to the exact tag shape the SSR runtime
+ * emits for lazy-registered assets (`data-asset` marks the SSR'd copy so
+ * `devStylePatch` knows which twin to drop when Vite's client injects its
+ * own), so the dedup story is identical for entry styles and lazy styles.
+ */
+export declare function renderDevStyleTag(desc: DevStyleDescriptor): string;
+/**
+ * Browser URL for a lazy module's dev asset key (a project-root-relative
+ * path, query included when the module identity carries one). Vite only
+ * serves module URLs under the configured `base`, so it is always applied;
+ * root-external keys (`../…`, e.g. sibling workspace packages) can't be
+ * expressed as root-relative URLs at all — they get Vite's `/@fs/` form on
+ * the resolved absolute path instead. Mirrored by the generated fallback in
+ * `devManifestCode` (src/index.ts) — keep the two in sync.
+ */
+export declare function devModuleUrl(root: string, base: string, key: string): string;
+export declare function createDevAssetResolver(server: ViteDevServer): DevAssetResolver;

package/dist/types/src/environment.d.ts

@@ -0,0 +1,13 @@
+/**
+ * Cross-instance-safe stand-in for vite's `isRunnableDevEnvironment`.
+ *
+ * Vite's helper is an `instanceof RunnableDevEnvironment` check against the
+ * class of whichever `vite` module the CALLER imported. When this plugin is
+ * consumed through a workspace/`link:` install, its own `vite` import can
+ * resolve to a different physical copy than the one running the dev server —
+ * and then the `instanceof` is false for every environment, silently standing
+ * the SSR/dev middlewares down. The `runner` accessor is the type's defining
+ * member (`RunnableDevEnvironment` is exactly "a DevEnvironment with a
+ * runner"), so presence-check it instead of trusting class identity.
+ */
+export declare function isRunnableEnvironment(environment: unknown): boolean;

package/dist/types/src/http.d.ts

@@ -0,0 +1,10 @@
+import type { IncomingMessage, ServerResponse } from 'node:http';
+/**
+ * `urlPath` overrides `req.url` when the middleware needs to dispatch a
+ * different URL than the one node saw — the dev middlewares use it to
+ * restore the configured Vite `base` that the dev/preview base middleware
+ * stripped, so the handler always sees production-shaped URLs.
+ */
+export declare function webRequestFromNode(req: IncomingMessage, urlPath?: string): Request;
+export declare function sendWebResponse(res: ServerResponse, response: Response): Promise<void>;
+export declare function joinBase(base: string, pathname: string): string;

package/dist/types/src/index.d.ts

@@ -0,0 +1,220 @@
+import * as babel from '@babel/core';
+import type { TransformOptions as JsxCompilerOptions } from '@dom-expressions/compiler';
+import { serverFunctions, type ServerFunctionsOptions } from './server-functions/index.js';
+import { type StartOptions } from './ssr/index.js';
+export { devStylePatch } from './dev-manifest.js';
+export { serverFunctions };
+export type { ServerFunctionsOptions };
+export type { ServerFunctionsFilter } from './server-functions/index.js';
+export type { StartOptions };
+import type { FilterPattern, Plugin } from 'vite';
+/** Possible options for the extensions property */
+export interface ExtensionOptions {
+    typescript?: boolean;
+}
+export type Compiler = 'babel' | 'native';
+export type SolidOptions = Omit<JsxCompilerOptions, 'filename' | 'sourceMap'>;
+/** Configuration options for @solidjs/vite-plugin. */
+export interface Options {
+    /**
+     * A [picomatch](https://github.com/micromatch/picomatch) pattern, or array of patterns, which specifies the files
+     * the plugin should operate on. Relative patterns are resolved against the
+     * Vite root, not the invocation directory.
+     */
+    include?: FilterPattern;
+    /**
+     * A [picomatch](https://github.com/micromatch/picomatch) pattern, or array of patterns, which specifies the files
+     * to be ignored by the plugin. Relative patterns are resolved against the
+     * Vite root, not the invocation directory.
+     */
+    exclude?: FilterPattern;
+    /**
+     * This will inject solid-js/dev in place of solid-js in dev mode. Has no
+     * effect in prod. If set to `false`, it won't inject it in dev. This is
+     * useful for extra logs and debugging.
+     *
+     * @default true
+     */
+    dev?: boolean;
+    /**
+     * Whether the app is server-rendered — one meaning everywhere.
+     *
+     * Without {@link start}: the legacy transform-only flag, unchanged.
+     * `true` enables the SSR transforms (hydratable client code, SSR server
+     * code) — you provide the entries and the server yourself.
+     *
+     * With {@link start}: selects the start mode. `true` is SSR start mode
+     * (per-request streaming render + hydration); `false`/omitted is client
+     * mode (a static document shell + client-side `render()`). Flipping a
+     * start-mode project between SPA and SSR is toggling this one boolean.
+     *
+     * The flag describes the app's initial document, not the internal
+     * pipelines — client mode still compiles the document shell through the
+     * SSR transforms to serve/prerender it.
+     *
+     * Objects are no longer accepted: start-mode options moved to {@link start}
+     * (`ssr: { ... }` from 3.0.0-next.23 and earlier becomes
+     * `start: { ... }, ssr: true`).
+     *
+     * @default false
+     */
+    ssr?: boolean;
+    /**
+     * Start mode — Start as a mode of the plugin: it owns entries, dev
+     * serving, and the build — no index.html, no mount file, no server
+     * wiring. `start: true` is the zero-config spelling, sugar for the empty
+     * options bag `start: {}` (both mean the identical start mode with
+     * defaults; `false`/absent is off). Conventions (shared by both modes,
+     * so projects flip between them by toggling {@link ssr}): `src/App.*`
+     * (or `start.app`) is the root component; `src/Document.*` (or
+     * `start.document`) is the optional document shell; authored
+     * `src/entry-server.*` / `src/entry-client.*` (or `start.entryServer` /
+     * `start.entryClient`) replace the generated entries.
+     *
+     * With `ssr: true` — SSR start mode:
+     *
+     * - Dev: a middleware on the Vite dev server streams the rendered app for
+     *   HTML-accepting GET requests — `vite` just works, no server file.
+     * - Build: a plain `vite build` produces both bundles (client to
+     *   `dist/client`, server to `dist/server` via the environments/builder
+     *   API). The server bundle's entry is `virtual:solid-ssr-handler`, whose
+     *   `handleRequest(request)` export maps a web `Request` to a streamed
+     *   `Response`; its default `{ fetch(request) }` export provides the same
+     *   handler in the Fetchable shape used by deployment integrations.
+     *   The normal `ssr` environment exposes it as the `index` service entry
+     *   so provider Vite plugins can supply the runtime and build orchestration.
+     * - With `serverFunctions` also enabled, the prod handler serves the
+     *   server-function endpoint too (in dev the server-function middleware
+     *   already runs first).
+     *
+     * Without `ssr: true` — client mode:
+     *
+     * - Dev: every HTML-accepting GET streams the rendered document shell
+     *   (without the app — history-fallback semantics); the generated client
+     *   entry `render()`s the app into it.
+     * - Build: `vite build` emits a static `dist/client` — the shell is
+     *   prerendered once through the built handler into
+     *   `dist/client/index.html` with the hashed entry script and CSS links —
+     *   deployable to any static host. No server bundle remains unless
+     *   `serverFunctions` is enabled, in which case `dist/server` is kept and
+     *   its `handleRequest` serves the endpoint (pages stay static).
+     * - Client code stays non-hydratable (`generate: 'dom'`), exactly like a
+     *   plain SPA; server-only options (`entryServer`, `external`) are inert.
+     * - `vite preview` serves the static build with history fallback (and
+     *   dispatches the server-function endpoint through the kept handler).
+     *
+     * @default undefined
+     */
+    start?: boolean | StartOptions;
+    /**
+     * JSX compiler backend to use. The default `"native"` compiles through
+     * `@dom-expressions/compiler`; `"babel"` is the escape hatch running
+     * `babel-preset-solid` instead — if native output ever differs from your
+     * expectations, set `compiler: "babel"` and file an issue (the behavioral
+     * diff between the modes is the bug report). Platforms without a prebuilt
+     * native binary (e.g. StackBlitz WebContainers) automatically use the wasm
+     * fallback; the compiler package itself is required in every mode.
+     *
+     * @default "native"
+     */
+    compiler?: Compiler;
+    /**
+     * This will inject HMR runtime in dev mode. Has no effect in prod. If
+     * set to `false`, it won't inject the runtime in dev.
+     *
+     * @default true
+     * @deprecated use `refresh` instead
+     */
+    hot?: boolean;
+    /**
+     * This registers additional extensions that should be processed by
+     * @solidjs/vite-plugin.
+     *
+     * @default undefined
+     */
+    extensions?: (string | [string, ExtensionOptions])[];
+    /**
+     * Pass any additional babel transform options. They will be merged with
+     * the transformations required by Solid.
+     *
+     * Note: with `compiler: "native"` the plugin is normally fully Babel-free
+     * (native lazy/refresh/JSX passes). Supplying custom babel options
+     * reintroduces a Babel support pass ahead of the native JSX transform to
+     * host them.
+     *
+     * @default {}
+     */
+    babel?: babel.TransformOptions | ((source: string, id: string, ssr: boolean) => babel.TransformOptions) | ((source: string, id: string, ssr: boolean) => Promise<babel.TransformOptions>);
+    /**
+     * Pass any additional [babel-plugin-jsx-dom-expressions](https://github.com/ryansolid/dom-expressions/tree/main/packages/babel-plugin-jsx-dom-expressions#plugin-options).
+     * They will be merged with the defaults sets by [babel-preset-solid](https://github.com/solidjs/solid/blob/main/packages/babel-preset-solid/index.js#L8-L25).
+     *
+     * @default {}
+     */
+    solid?: SolidOptions;
+    /**
+     * Enable `"use server"` server function compilation (experimental). Pass
+     * `true` for the defaults (runtime from @solidjs/web/server-functions) or
+     * an options object to customize. The directive transform sub-plugins are
+     * emitted ahead of the JSX transform in the returned plugin array.
+     *
+     * Zero-config setup: in dev, a middleware on the Vite server handles the
+     * endpoint (default `/_server`, joined with `base`) end to end — no
+     * server-function code needed in the server entry. For production SSR
+     * builds, import `virtual:solid-server-function-handler` in the server
+     * entry and mount its `handleServerFunctionRequest(request)` export on the
+     * endpoint; it eagerly imports every module containing server functions so
+     * registrations survive tree-shaking.
+     *
+     * Hosts whose own server environment should own endpoint dispatch in dev
+     * (e.g. @cloudflare/vite-plugin, so functions run in workerd with
+     * bindings) can keep this option and set
+     * `serverFunctions: { devMiddleware: false }` — see
+     * {@link ServerFunctionsOptions.devMiddleware}. A server-only module can
+     * be pinned into the handler graph for pre-dispatch runtime registration
+     * via {@link ServerFunctionsOptions.configure}.
+     *
+     * Meta-frameworks that need to control plugin ordering themselves (e.g.
+     * relative to a file-system router) and dispatch requests through their
+     * own server should use the standalone `serverFunctions()` export instead,
+     * which never installs the dev middleware.
+     *
+     * The object form's `components` flag additionally enables server
+     * components (experimental) — `"use server"` functions returning a
+     * component, served over the same endpoint. They come essentially for
+     * free: the endpoint transform is installed automatically, and with
+     * SSR start mode (the `start` option with `ssr: true`) and generated entries
+     * the document wiring is emitted too. See
+     * {@link ServerFunctionsOptions.components}.
+     *
+     * @default undefined
+     */
+    serverFunctions?: boolean | ServerFunctionsOptions;
+    /** Options for the solid-refresh HMR transform (dev only). */
+    refresh?: RefreshOptions;
+}
+/** Options for the solid-refresh HMR transform (dev only). */
+export interface RefreshOptions {
+    /**
+     * Disable the refresh transform entirely (equivalent to the deprecated
+     * `hot: false`).
+     */
+    disabled?: boolean;
+    /**
+     * Emit per-component `signature`/`dependencies` metadata so edits only
+     * remount components whose code actually changed.
+     *
+     * @default true
+     */
+    granular?: boolean;
+}
+export default function solidPlugin(options?: Partial<Options>): Plugin[];
+export type ViteManifest = Record<string, {
+    file: string;
+    css?: string[];
+    isEntry?: boolean;
+    isDynamicEntry?: boolean;
+    imports?: string[];
+}> & {
+    _base?: string;
+};

package/dist/types/src/server-functions/compile.d.ts

@@ -0,0 +1,38 @@
+export interface NamedImportDefinition {
+    kind: 'named';
+    name: string;
+    source: string;
+}
+export interface DefaultImportDefinition {
+    kind: 'default';
+    source: string;
+}
+export type ImportDefinition = DefaultImportDefinition | NamedImportDefinition;
+export interface CompileOptions {
+    mode: 'server' | 'client';
+    env: 'production' | 'development';
+    /** The directive text (default "use server" upstream). */
+    directive: string;
+    /** Project root; function IDs hash the root-relative path. */
+    root: string;
+    definitions: {
+        register: ImportDefinition;
+        create: ImportDefinition;
+    };
+}
+export interface CompileResult {
+    valid: boolean;
+    code: string;
+    map: string | null;
+    functions: import('@dom-expressions/compiler').ServerFunctionMeta[];
+}
+/**
+ * Runs the directive transform over one module. Function IDs are
+ * `hash(relative path)-<counter>`, so the client and server builds of the
+ * same checkout agree on every ID (the wire contract) without baking
+ * machine-specific absolute paths into the output. A `valid: false` result
+ * means the module contained no matching directive and must be left
+ * untransformed. Invalid closure captures (a server function referencing a
+ * non-top-level binding) throw with the variable name and location.
+ */
+export declare function compile(id: string, code: string, options: CompileOptions): Promise<CompileResult>;

package/dist/types/src/server-functions/index.d.ts

@@ -0,0 +1,145 @@
+import { type FilterPattern, type Plugin } from 'vite';
+/**
+ * Picomatch patterns selecting the modules the directive compiler runs on.
+ * Relative patterns (the defaults included) are resolved against the Vite
+ * root — not the invocation directory — so running `vite` from outside the
+ * project keeps compiling the same files. Absolute patterns are used as-is.
+ *
+ * @default include "src/**\/*.{jsx,tsx,ts,js,mjs,cjs}", exclude "node_modules/**\/*.{jsx,tsx,ts,js,mjs,cjs}"
+ */
+export interface ServerFunctionsFilter {
+    include?: FilterPattern;
+    exclude?: FilterPattern;
+}
+export interface ServerFunctionsOptions {
+    /**
+     * Module specifiers the compiled output imports the runtime from.
+     * Each must export `registerServerReference(id, fn)` (server) and
+     * `createServerReference(...)` (both sides).
+     *
+     * @default "@solidjs/web/server-functions" for both (the package's export
+     * conditions resolve the client or server half per environment)
+     */
+    runtime?: {
+        server: string;
+        client: string;
+    };
+    /**
+     * Virtual module id that imports every module containing server functions.
+     * Import it for side effects in your server entry so all registrations
+     * exist before requests are handled.
+     *
+     * @default "virtual:solid-server-function-manifest"
+     */
+    manifest?: string;
+    filter?: ServerFunctionsFilter;
+    /**
+     * @default "use server"
+     */
+    directive?: string;
+    /**
+     * Path the server-function transport posts to. Joined with Vite `base`.
+     * Threaded to the built-in dev middleware, the
+     * `virtual:solid-server-function-handler` module, and — whenever the
+     * resolved path differs from the runtime default (`/_server`) — runtime
+     * `configureServerFunctions{Client,Server}` calls appended to compiled
+     * modules (so custom runtimes used with a custom endpoint must export
+     * those).
+     *
+     * @default "/_server"
+     */
+    endpoint?: string;
+    /**
+     * Whether the built-in dev middleware owns the server-function endpoint on
+     * the Vite dev server. Only meaningful through the main plugin's
+     * `serverFunctions` option (the standalone `serverFunctions()` export
+     * never installs the middleware).
+     *
+     * Set `false` when another plugin's server environment should own
+     * dispatch in dev — e.g. @cloudflare/vite-plugin, whose workerd
+     * environment carries the bindings (`env`/`ctx`) your server functions
+     * need: the middleware executes functions in Vite's node-side SSR
+     * environment, so with it installed those requests never reach the
+     * worker. With the middleware off, everything else keeps working —
+     * compilation, the manifest and handler virtual modules — and endpoint
+     * requests fall through to whatever the host serves; the host loads
+     * `virtual:solid-server-function-handler` itself and dispatches through
+     * its `handleServerFunctionRequest` export, exactly like production.
+     * Functions referenced only by client code register on demand through
+     * the middleware in dev, so a host owning dispatch should side-effect
+     * import the manifest module in its server entry to cover them.
+     *
+     * When a provider owns the dev server's `ssr` environment (it isn't
+     * runnable), the middleware already stands down automatically — no need
+     * to set this. See `start.external` for the whole-server switch.
+     *
+     * @default true (stands down automatically when the `ssr` dev environment isn't runnable)
+     */
+    devMiddleware?: boolean;
+    /**
+     * Path to a server-only module (resolved relative to the Vite root, like
+     * `start.document`) that the generated
+     * `virtual:solid-server-function-handler` module side-effect imports
+     * before configuring the runtime. A guaranteed pre-dispatch home for
+     * server-side registration — typically `configureServerFunctionsServer`
+     * calls whose config the app graph can't reliably install first, e.g. a
+     * router's single-flight collector:
+     *
+     * ```ts
+     * // src/server-config.ts
+     * import { configureServerFunctionsServer } from '@solidjs/web/server-functions/server';
+     * configureServerFunctionsServer({ collectFlightData: createFlightDataCollector(router) });
+     * ```
+     *
+     * Because the module lives in the handler graph, it is evaluated before
+     * any dispatch on every surface — the dev middleware and the production
+     * handler alike — and is immune to the dev-restart race where
+     * registration living in the app graph only loads with the first page
+     * render (the handler graph loads before the first mutation). Config
+     * calls merge per key, so it composes with the plugin's own
+     * `configureServerFunctionsServer` call in the same module.
+     *
+     * @default undefined
+     */
+    configure?: string;
+    /**
+     * Enable server components (experimental): `"use server"` functions that
+     * return a component. Responses for them are served over the
+     * server-function endpoint as streamed HTML that the client runtime
+     * applies in place of the boundary (instead of decoding it as data).
+     *
+     * The plugin's dispatch surfaces — the built-in dev middleware and the
+     * `virtual:solid-server-function-handler` module — install the response
+     * transform on the server runtime automatically, so this needs no
+     * per-request wiring or server code.
+     *
+     * Document SSR of server components (rendered inline at t=0 and adopted
+     * at boot with zero endpoint requests) needs three more pieces: the
+     * render must run with the server-component render plugin, the document
+     * must carry the bootstrap script, and the client must call
+     * `installServerComponents()` before hydrating. With SSR start mode (the
+     * main plugin's `start` option with `ssr: true`) and generated entries
+     * the plugin emits all three. With authored entries those pieces live in
+     * your entry files — import them from `@solidjs/web/frames` (see the
+     * README).
+     *
+     * All of this is pure codegen: when the option is off, no reference to
+     * the server-component runtime is emitted anywhere.
+     *
+     * @default false
+     */
+    components?: boolean;
+}
+/**
+ * The second parameter is internal wiring for the main plugin's
+ * `serverFunctions` option: the built-in dev middleware is only installed
+ * through that path, so meta-frameworks composing this factory directly
+ * (and dispatching to `handleServerFunctionRequest` themselves) never race
+ * it for the endpoint. On the main plugin's path the public
+ * `options.devMiddleware` (default true) can opt back out of it.
+ */
+export declare function serverFunctions(options?: ServerFunctionsOptions, internal?: {
+    devMiddleware?: boolean;
+    externalDevServer?: boolean;
+    ssrHandler?: string;
+}): Plugin[];

package/dist/types/src/server-functions/xxhash32.d.ts

@@ -0,0 +1,5 @@
+/**
+ * @param buffer - byte array or string
+ * @param seed - optional seed (32-bit unsigned)
+ */
+export default function xxHash32(buffer: Uint8Array | string, seed?: number): number;