ui-router-server / vite / ServerRouterPluginOptions
Interface: ServerRouterPluginOptions
Defined in: vite.ts:135
Options for serverRouterPlugin: the Connect adapter's, plus the build step; the base comes from Vite's config.
Extends
Properties
| Property | Type | Description | Overrides | Inherited from | Defined in |
|---|---|---|---|---|---|
base? | string | Checked against Vite's resolved base, which the router's base sets when Vite's is unset; a different value throws. | ConnectAdapterOptions.base | - | vite.ts:137 |
delegates? | "next" | How delegating states are served. Connect has no fetch-shaped handler bridge, so 'next' is the only mode: a navigation that matches a delegating state passes to the downstream stack, which must serve it. Without it, construction throws for a router from createServerRouter that names delegate keys, and a structural router's delegate verdict fails the request through next(error). | - | ConnectAdapterOptions.delegates | connect.ts:140 |
prerender? | string | PrerenderOptions | Prerenders the app after vite build. entry names the prerender script, resolved against Vite's root, whose default export is a PrerenderEntry; a string is shorthand for { entry }. The script runs in a worker_thread of its own, after any preload modules, so nothing it installs reaches Vite's process. It is loaded through a Vite module runner with the root and mode, without the app's plugins, and its dependencies load from node. vite preview then serves each page the build wrote, and 404.html for a path the otherwise rule sends to a 404 state, while redirects and plain 404s still answer through the middleware. A serveShell passed here replaces that. See https://lit-ui-router.dev/guides/prerender-with-vite | - | - | vite.ts:156 |
responses? | "next" | How response states are served, as for delegates: 'next' passes a navigation that matches one to the downstream stack, which must answer it. Without it, construction throws for a router from createServerRouter that declares response states, and a structural router's response verdict fails the request through next(error). | - | ConnectAdapterOptions.responses | connect.ts:148 |
serveNotFound? | (mount, req, res, next) => void | Serve a mount-owned miss (notFound with a mount: the mount owned the pathname but no route matched). The default answers a minimal text/plain 404 — override to serve a real 404 page. A notFound without a mount is never routed here: the pathname isn't this router's, so the middleware always passes it through untouched. | - | ConnectAdapterOptions.serveNotFound | connect.ts:116 |
serveShell? | (mount, req, res, next, verdict) => void | Serve the mount's shell. The default rewrites req.url to shellPath and next()s into the downstream static layer. By the time this runs the adapter has already done the status'd-shell mechanics: request validators stripped and the response relabeled to the verdict's status — a host override only owns the asset IO. The verdict arrives last, so a host can serve a 404 page for the otherwise projection's status. | - | ConnectAdapterOptions.serveShell | connect.ts:102 |
shellPath? | (mount) => string | Maps a shell verdict's mount to the path the default serveShell rewrites req.url to (default: the mount base itself). The hook for aliased mounts whose shell lives under another prefix. | - | ConnectAdapterOptions.shellPath | connect.ts:92 |
shouldHandle? | (req) => boolean | Which requests get verdicts. The default is the navigation heuristic connect-history-api-fallback established (and Vite's own HTML fallback mirrors): GET/HEAD requests whose Accept includes text/html. Module and asset fetches (Accept: */*) pass through untouched — essential under Vite, where a mount's module URLs live on the same paths as its routes. Override with () => true when the middleware sits behind the static layer and should judge everything. | - | ConnectAdapterOptions.shouldHandle | connect.ts:131 |