generouted: file-based routes for Vite, generated at build time from a pages directory

What it does: a glob import and a set of naming conventions

generouted uses Vite's glob import API to list the routes within the src/pages directory and generates the routes tree and modals based on generouted's conventions. That is the entire mechanism, and it is a build-time transform rather than a runtime router. The motivation section explains the origin, that the author enjoyed file-based routing since trying the Next.js pages directory, applied the same concept with Vite and client-side applications, and wrote blog posts on implementing client-side file-based routing with React Router before packaging it as generouted. The design goal is inherited from Next.js, Remix, Expo, Docusaurus and SvelteKit, and the README is explicit that generouted is client-side. There are also Vite plugins available for some integrations to provide type-safe components, hooks and utilities through code generation, which is the piece that makes the navigation type-safe rather than merely convenient.

The feature list, which is really a list of routing conventions

The features are all routing ideas, and reading them together tells you what the conventions support. Client-side file-based routing, powered by Vite. React support with react-router or the TanStack Router or the older TanStack React Location. Solid support with the Solid router. File-based MDX routes with React or Solid, which require the @mdx-js/rollup package. Type-safe navigation and type-safe global modals. Route-based code-splitting and lazy-loading. Route-based data loaders and actions, and a route-based error boundary. Nested layouts and pathless layout groups, which is the pattern for sharing a layout across routes that are not grouped by path. Optional static and dynamic routes. And ignored routes per file or directory, which is how you exclude something from the tree without moving it out of the tree. Every one of these is a filename convention, so the documentation is really a spec for what file names mean.

Setting up React Router: one package, one plugin, one component

The React Router setup is the shortest path and it is three steps. You install with pnpm add @generouted/react-router react-router. You add the plugin to your Vite config, importing generouted from the plugin entry point and passing it into the plugins array alongside the React plugin, so the defineConfig call has plugins: [react(), generouted()]. And in your main entry file you import Routes from @generouted/react-router and render it into the root element with createRoot. That is the whole wiring, and it is worth noticing what is absent, there is no route table to declare, no provider to wrap, and no configuration of routes. The routes come from the filesystem.

pnpm add @generouted/react-router react-router

// vite.config.ts
import { defineConfig } from 'vite'
import react from '@vitejs/plugin-react'
import generouted from '@generouted/react-router/plugin'

export default defineConfig({ plugins: [react(), generouted()] })

// src/main.tsx
import { createRoot } from 'react-dom/client'
import { Routes } from '@generouted/react-router'

createRoot(document.getElementById('root')!).render(<Routes />)

Adding a page: create a file, export a default component

The Adding pages instruction is the same for both routers. You create a new file src/pages/index.tsx for the home page, which maps to the root path, and you export a default component from it, so a Home function returning an h1 element. There is no registration step, no import into a routes file, and no name to match. The mapping from filename to path is the convention, and the README refers you to the routing conventions section for the details. The Solid setup differs only in the details, since you install @generouted/solid-router alongside the Solid router, the plugin import comes from that package, and the entry point uses render from solid-js/web rather than createRoot, but the page file convention is identical. That consistency is the point of the project, and it is what makes the Solid and React flavours feel like one tool rather than two.

export default function Home() {
  return <h1>Home</h1>
}

Two integrations in warning territory, and what to pick instead

The README marks two of the router integrations explicitly. TanStack React Router is labelled in-progress experimental support, with its own documentation under packages/tanstack-react-router and a basic example. React Location is labelled deprecated, and its installation is different, using the generouted package rather than a scoped one, with the import of Routes coming from generouted/react-location. The deprecated one is the older path and it is not where a new project should start. The feature list also carries the React support line with a laboratory emoji and a warning emoji, and the TanStack entry has the experimental marker, so the signal is that the stable combinations are react-router and the Solid router, with everything else in some form of transition. The example directories confirm it, since there are separate examples for react-router, react-router-custom, react-router-custom-path, react-router-mdx, react-router-route-modals, solid-router and tanstack-react-router, and one for react-location.

The interactive explorer, and why it matters for a convention-driven tool

There is an online explorer, a StackBlitz project at the explorer directory in the repository, described as generouted's interactive playground. You can explore file-based routing patterns and conventions, visualize the routes, layouts and the resolved routes paths, and update the src/pages files and see your changes reflected. For a tool whose entire user interface is a set of filename rules, this is the documentation that does the most work, because a table of rules tells you what is possible while the playground shows you what a particular structure resolves to. The homepage of the project points at the same StackBlitz explorer, so it is the intended first contact for someone evaluating the conventions rather than the API.

The monorepo, the release tooling and where the project stands

The repository is a pnpm workspace with turbo, and the root package.json gives the shape. The package manager is pnpm 9.0.0, the scripts are build, test and type-check all delegated to turbo, plus release-it for releases and husky for the prepare hook. The release tooling is configured in a .release-it.json with commitlint.config.js alongside it for conventional commits, and lint-staged.config.js and prettier.config.js for the formatting side. The workspace contains packages/ for the published packages, examples/ for the eight example projects, explorer/ for the playground, and shared/ for code common to the packages. The last push to the repository was on 2026-04-05, the repository is not archived, the licence is MIT, and the recent releases are v1.20.0 from 2025-02-07, v1.20.1 from 2026-03-14 and v1.20.2 from 2026-03-15.

Editorial conclusion

generouted suits a Vite team that wants the Next.js pages directory convention in a client-side application, with type-safe navigation and route-based splitting, and that is happy to have its routes generated rather than declared. It is the wrong choice for a server-rendered application, since the whole thing is described as client-side file-based routing, and a poor fit if you want a single framework-agnostic convention, because the conventions and the type-safety story differ per router package. Before adopting it, read the conventions section and the interactive explorer, because the route file naming rules are the whole API, and note that the README marks the TanStack Router support as in-progress experimental and the React Location integration as deprecated, so a new project should start on the react-router or solid-router packages.

Frequently asked questions

Official sources

1. License: MIT
2. oedotme/generouted on GitHub
3. Project website
4. README
5. Releases