Move parts of File Routing from Start to Router

[birkskyum]

Right now all fs routing lives in start, but it could be distributed better like:

Feature	Owner
<Router>, matching, and navigation	@solidjs/router
RouteDefinition and the route export contract	@solidjs/router
<FileRoutes> runtime component	@solidjs/router/fs
Scan the filesystem	@solidjs/router-vite
Convert filenames into paths	@solidjs/router-vite
Analyze route-module exports	@solidjs/router-vite
Generate virtual route modules	@solidjs/router-vite
Route HMR and code splitting	@solidjs/router-vite
GET, POST, etc. route exports	@solidjs/start
API matching and request handling	@solidjs/start
Server functions and middleware	@solidjs/start
SSR and Vite environments	@solidjs/start

Usage example

Router app

The router's Vite integration composes with the separate Solid plugin:

import { solidRouter } from "@solidjs/router-vite";
import { defineConfig } from "vite";
import solid from "vite-plugin-solid";

export default defineConfig({
  plugins: [solid(), solidRouter()],
});

SolidStart app

SolidStart configures Solid and the router. Add Nitro when the app needs a
server runtime and deployment presets:

import { solidStart } from "@solidjs/start/config";
import { nitro } from "nitro/vite";
import { defineConfig } from "vite";

export default defineConfig({
  plugins: [solidStart(), nitro()],
});

[ryansolid]

THis is pretty close to alignment here. The only thing I wonder is if the filesystem router is more generalizeable than Solid Router.. It doesn't have to be. But it is more of a protocol than a specific implementation. In recent similar decisions it actually has led me to hoisting stuff even further up. That might be overstepping but I just had an idea of pulling it all the way up to our Rust super compiler.. Its a tool that projects/routers can hook into. Arguably this could be even framework agnostic but that isn't really our goal is it. It's Solid agnostic so it might be fine as an optional layer for any Solid project.

[ryansolid]

Been thinking about this more, and I want to refine what I said about hoisting into the compiler — I think the right split is shapes vs machinery, and my compiler idea got the machinery boundary wrong.

The genuinely protocol-shaped piece is the route contract: RouteDefinition, the route export shape, what a route module means. That's @solidjs/router's to own for its consumers, and it's the piece worth being opinionated about.

The compiler's role should stay narrow: it's a stateless per-file transformer, so a stateful project-layout scanner doesn't belong in it. The one slice that is compiler-shaped is route-module export analysis ("what does this module export, which exports are server-only") — it already does that kind of reporting for server functions, so it can expose export analysis as a generic service without ever knowing what a route is.

The bigger amendment to the table: the FS layer can't belong to Solid Router. Start is bring-your-own-router, and if file routing ships as @solidjs/router-vite, the file-routing story quietly becomes Solid-Router-only. So I'd structure it the way we've structured everything else this cycle — shared analysis, per-consumer emission:

• A router-neutral package — @solidjs/file-routes or similar — whose core is bundler-agnostic: scanning, the filename convention (pluggable: a function from file tree to a neutral route manifest — paths, params, layouts, module refs, export info), and emission seams.
• Each router ships a small emission adapter turning the manifest into its own route definitions — Solid Router's emits RouteDefinitions and ships <FileRoutes>; other routers emit their own shapes.
• Delivery is an adapter layer too, with Vite as the first entry (@solidjs/file-routes/vite: virtual modules + HMR invalidation). The core itself doesn't know about Vite — same decomposition as refresh (agnostic transform + runtime, thin hot-wiring glue) and the server-function compiler (pure transform, Vite orchestration). TanStack Router proves the shape: their file routing runs as a Vite plugin or a standalone generator off the same core.
• Start composes whichever router/adapter pair the app chose and owns only its server conventions (API routes, middleware).

The conventions themselves can start as exactly what Start has already proven — I don't want to design a universal convention language up front — but the manifest, adapter, and delivery seams are where the openness lives, and those are worth getting right from the start.