ui-router-server / ui-router-server / MountConfig

Interface: MountConfig<R>

Defined in: index.ts:67

One mount's routing configuration: its state tree, its redirects, and the tier that resolves them. R is the type of routes; an as const array types the router's delegate keys, response states and state names (see ServerRouter).

Type Parameters

Type Parameter	Default type
R extends readonly RouteDeclaration[]	readonly RouteDeclaration[]

Properties

Property	Type	Description	Defined in
config?	RouteTableConfig	Url options (defaults: strict, case-sensitive, no squash, slashes as requested); 'simulate' mounts apply all but decodeParams. Hand the same object to `applyUrlConfig` on the client router so both sides compile and format urls alike. Under a trailingSlash policy, a url matching a state in the other spelling verdicts as a 308 redirect to the canonical one.	index.ts:92
ignoreDiagnostics?	readonly "bareBaseNotFound"[]	Diagnostic kinds this mount means to trip, turned off for it alone: the construction warning skips them and diagnoseMounts omits them, so development and CI agree. A kind outside MountDiagnosticKind throws at construction. Example import type { MountConfig } from 'ui-router-server'; // /api owns its bare base and answers it with a 404 on purpose. const mounts = { '/api': { routes: [{ name: 'item', url: '/items/:id' }], ignoreDiagnostics: ['bareBaseNotFound'], }, } satisfies Record<string, MountConfig>;	index.ts:161
otherwise?	{ state: string; }	Projection of the client's otherwise() rule. state references a declared, url-less state (url-less so the unmatched url stays in the address bar, like a server 404 — mirroring the real rule's semantics). When declared, unknown paths under this mount verdict as shell with status 404: the resource genuinely doesn't exist and the shell IS the error page (never 200) — the client boots at the retained path and its own otherwise rule renders the rich notFound state. Redirect rules and route matches take precedence; undeclared keeps the notFound verdict.	index.ts:122
otherwise.state	string	Name of the declared, url-less state unknown paths verdict as.	index.ts:124
prewarm?	number	Idle headless routers a 'simulate' mount builds once @uirouter/core loads, so its first requests skip the cold build. Default 0: the pool builds on demand. An integer from 0 to 16 (the pool's idle cap); any other value, or a positive count on a 'matcher' mount, throws at construction. A failed prewarm build is dropped silently and requests build on demand. The builds chain onto the import that construction starts, ahead of every request on the mount, so the first request never races them and there is nothing extra to await. In a Cloudflare Worker that constructs its router at module scope, the builds may run during startup: they do no I/O, timers or randomness, so global scope permits them, but their CPU counts toward the Worker's startup time limit.	index.ts:141
redirects?	RedirectRule[]	when()-style pattern rules, evaluated before per-state redirectTo entries.	index.ts:73
routeIndex?	RouteIndex	How a 'matcher' mount looks up the route a pathname matches. Default: a linear scan that tries every route. routeTrie walks a segment trie to the few routes whose spelling fits, with the same verdicts, and throws at construction for a route it can't express. Only the index a mount names is bundled. On a 'simulate' mount it throws at construction. Example import { routeTrie } from 'ui-router-server'; import type { MountConfig } from 'ui-router-server'; const app: MountConfig = { routes: [{ name: 'home', url: '' }, { name: 'item', url: '/items/:id' }], routeIndex: routeTrie, };	index.ts:111
routes	R	The mount's state tree; dotted names nest, urls append (see RouteDeclaration).	index.ts:71
strategy?	"matcher" | "simulate"	'matcher' (default): dependency-free pattern matching plus data redirects. 'simulate': replay through a headless @uirouter/core router — the tier where routing that data cannot express (hooks, resolves, redirectTo functions) will live. Those are NOT yet reachable through MountConfig: both strategies consume the same RouteDeclaration data subset today, deliberately, so strategy stays a pure cost knob; the config widens later (e.g. an auth tier).	index.ts:83