Skip to content

ui-router-server / vite / ServerRouterPluginOptions

Interface: ServerRouterPluginOptions ​

Defined in: vite.ts:111

Options for serverRouterPlugin: the Connect adapter's, plus the build step.

Extends ​

Properties ​

PropertyTypeDescriptionInherited fromDefined in
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.delegatesconnect.ts:121
prerender?| string | { entry: string; }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 is loaded through Vite's 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:127
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.responsesconnect.ts:129
serveNotFound?(mount, req, res, next) => voidServe 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.serveNotFoundconnect.ts:97
serveShell?(mount, req, res, next, verdict) => voidServe 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.serveShellconnect.ts:83
shellPath?(mount) => stringMaps 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.shellPathconnect.ts:73
shouldHandle?(req) => booleanWhich 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.shouldHandleconnect.ts:112