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.

[brenelz]

Took a run at implementing the refined split — PR up at #572, building on #570's workspace layout:

• @solidjs/file-routes — bundler-agnostic core: BaseFileSystemRouter scans into a flat neutral manifest, the Start-proven filename convention ships as a pluggable default (PageFileSystemRouter), and export analysis sits behind its own seam (oxc-parser) so a compiler could provide it later. Server conventions (GET/POST exports) deliberately excluded.
• @solidjs/file-routes/vite — delivery adapter: serves the manifest as the solid:file-routes virtual module (lazy $ refs → code-split dynamic imports, eager $$ refs → static imports, tree-shaken per export), watcher-driven HMR, and per-Vite-environment routers so Start can compose different conventions for client/ssr.
• @solidjs/router/fs — Solid Router's emission adapter (~100 lines): createFileRoutes nests the manifest, strips (group)s, merges route configs into lazy RouteDefinitions, and ships <FileRoutes />. The router does not depend on file-routes, so bring-your-own-router is preserved.

The repo now also carries examples/file-routes — a plain Vite + Solid Router SPA with file routing, no Start — which was the gap this discussion opened with.

To gauge what the seam buys on the Start side: a draft migration of Start (off upgrade-to-solid-2-beta) onto these packages is +39 / −1,344 lines — Start keeps only SolidStartServerFileRouter (HTTP export conventions + dataOnly) extending the shared page convention, and composes fileRoutes({ routers }). Typechecks clean and Start's remaining tests pass against a local link; blocked on @solidjs/file-routes publishing. Branch: https://github.com/brenelz/solid-start/tree/file-routes-migration