v2.0.0-next.28

Patch Changes

• 5db7339: File-system routes can be server component pages. With fileRoutes({ serverComponents: true }) on the file-routes plugin, a route file whose default export is a "use server" function of the route args becomes serverRouteComponent(query(fn, key)) keyed by the file's path — or through the wrapper its route config names, defineFileRoute(path, { query: liveQuery }), which that file imports so only a live app carries it, so revalidate("src/routes/stories") reaches every page under a directory. ServerRouteArgs<typeof route> types params from the pattern and search from the schema's output. The wiring lives in a module the adapter reaches only behind serverRoutes from filesystem-routing/flags (a new optional peer), which the plugin folds from its scan, so apps without a server page bundle none of it; pnpm build asserts this. A code-split page that turns out to be a server function throws a directed error.
• 1bba2a5: Router.keysFor(url): the query keys of the server component routes a URL shows, root to leaf — the app's query key for a hand-written route, the file for a file-system route. Pure matching over the instance's tree, so a server action can narrow reload/respond/redirect's revalidate to what a mutation changed (reload({ revalidate: Router.keysFor(paths.stories(id)) })) without spelling a key; a paths node is accepted.
• b8013d3: Hover/intent preload only runs a route level's data preload (its preload and a server component route's source call) when navigation would mount that level fresh or reuse it with changed inputs: the level's params, and search as the declared schema's validated output, or the raw search string when the route declares no schema. Previously every matched level re-ran on each hover, so a shared layout's preload fired on every link. Lazy component code preloads are unaffected.
• 5c4033c: Smaller client footprint for the server route pieces: the fs adapter's code-split server-function check and the long direct-mount message of serverRouteComponent are development-only (DEV &&, folded out of shipped bundles), useSearchParams and the server route args share one Standard Schema validation helper, and the brand lookup and args equality are tightened. Behavior is unchanged; in production the fs adapter is ~380 bytes minified and the server route wrapper ~215.
• 47a963b: serverRouteComponent(source) (experimental) now takes the app's query over the server component rather than wrapping the raw "use server" function in query itself: serverRouteComponent(query(storyView, "story")). The router still derives the arguments from the match, mounts the result with the outlet as children, and calls the same source under preload intent — link hover and the single-flight collector — but the cache strategy and the key are the source's. That makes the key nameable (revalidate("story") reaches the route; the "route:" + fn.id key of 2.0.0-next.27 was not) and lets the source be a liveQuery, whose channel contract (hover connects and holds through the preload window, revalidate reconnects, the sweep leaves it alone, nothing pulls it in the collector) applies unchanged. ServerRouteFunction widens to a function of ServerRouteArgs answering a component once, as a promise, or as successive values; ServerRouteView names the component type. Breaking for 2.0.0-next.27 callers: wrap the function in query(). Mounting the returned component directly — through lazy(), or outside a route — now throws: only the router's mount derives this level's arguments, and a direct mount would put the same view under a second address.
• e6466ba: serverRouteComponent accepts a source that ignores its arguments — an app shell — after query() has typed it as (...args: never[]).
• 5c75fb5: Submission.retry is typed as returning the action's result promise, matching what it always returned (#613).