Framework Packages

Purpose and Scope

TanStack Router is shipped as a monorepo rather than a single framework-only package. The public surface is organized around a framework-neutral routing core, framework adapters for React, Solid, and Vue, development tooling, and TanStack Start packages that build a full-stack framework on top of Router. This page helps you decide which package family you are looking at before you move into installation, API reference, or framework-specific examples. The most important rule is that application code normally imports the adapter for the UI framework, while build tools, devtools, and Start packages sit beside that adapter to provide typed file routes, debugging, and server-oriented capabilities.

Sources: docs/router/devtools.md

The supplied devtools documentation is a useful example of how this package split appears to application developers. It presents Router devtools as separate packages from the main router adapter, and it shows framework-specific imports for React and Solid rather than a single universal component. That pattern is repeated throughout the repository: shared concepts live in core packages and docs, but the package you install or import is selected by runtime framework and by task. A React app reaches for React Router and React Router Devtools; a Solid app reaches for the Solid equivalents; Vue has its own Router package family even when a particular guide focuses on React and Solid examples.

Sources: docs/router/devtools.md

Relevant Source Files

• docs/router/devtools.md - Documents the framework-specific devtools packages, their installation names, production import variants, root-route usage, manual router wiring, and floating-mode behavior.

Package Families at a Glance

The Router package family starts with @tanstack/router-core, which is the framework-independent routing engine. It is where the shared ideas of route matching, router state, navigation decisions, locations, search parsing, loaders, and errors belong conceptually. Most application developers do not import from core directly; they consume the adapter package for their framework. The React adapter is @tanstack/react-router, the Solid adapter is @tanstack/solid-router, and the Vue adapter is @tanstack/vue-router. These framework packages expose the same Router model through framework-native components, hooks, providers, and route creation helpers.

Devtools are intentionally separate from the router adapters. The docs describe Router devtools as a package you install in addition to the router package, with React using @tanstack/react-router-devtools and Solid using @tanstack/solid-router-devtools. The import examples use TanStackRouterDevtools, making the component feel like normal app UI while still connecting to the router instance for inspection. This separation keeps debugging UI optional and makes the production behavior explicit. If you import the normal devtools component, it is not shown in production; the documented production-oriented import is TanStackRouterDevtoolsInProd. Sources: docs/router/devtools.md

TanStack Start packages form a second layer above Router. Start is the full-stack framework family built on the Router model, adding server rendering, streaming, server functions, entry points, bundling integration, and deployment-oriented behavior. In the repository map, the main framework packages include @tanstack/react-start, @tanstack/solid-start, and @tanstack/vue-start, with shared client and server internals such as start client core, start server core, and plugin core packages. Treat these as Start packages rather than plain Router packages: they still rely on Router concepts, but they solve full-stack application concerns that are outside a client-side router adapter.

System-to-Code Mapping

This mapping is intentionally task-oriented. If you are authoring routes and links in a React single-page app, start with @tanstack/react-router. If you are debugging matching, pending states, route data, or navigation, add the devtools package for your framework. If you are adopting file-based routing, look at the router plugin and generator pages, because those packages participate at build time rather than at runtime. If you need SSR, streaming, server functions, and deployable full-stack behavior, move to the Start pages instead of trying to assemble those features from the router adapter alone.

Devtools as a Package Split Example

The devtools guide shows the repository's framework packaging philosophy in a concrete workflow. First, install the separate devtools package for the current framework. Second, import a framework-specific component. Third, render it near the root route so it can automatically connect to the router instance. In React, the documented root route example imports createRootRoute and Outlet from @tanstack/react-router, imports TanStackRouterDevtools from @tanstack/react-router-devtools, and renders the devtools next to the outlet. In Solid, the same pattern uses @tanstack/solid-router and @tanstack/solid-router-devtools. Sources: docs/router/devtools.md

import { TanStackRouterDevtools } from '@tanstack/react-router-devtools'

import { TanStackRouterDevtools } from '@tanstack/solid-router-devtools'

The guide also documents a manual wiring mode. If the devtools are rendered outside the provider subtree, the router prop accepts the same router instance passed to the application router provider. That detail matters for package selection because the devtools package is not a replacement router and does not create the app router for you. It is an observer UI that either discovers the router through placement inside the routed tree or receives the instance explicitly. Floating mode is another option: rendering TanStackRouterDevtools with initialIsOpen={false} mounts a fixed toggleable panel and remembers toggle state in localStorage. Sources: docs/router/devtools.md

Package Selection Workflow

Choose packages by answering three questions. First, which UI framework owns rendering? That determines whether your app imports from the React, Solid, or Vue router package. Second, do you need runtime application routing only, or do you also want build-time route generation? Runtime routing belongs to the framework adapter; file-route generation belongs to the plugin and generator packages. Third, are you building a client app or a full-stack Start app? Start packages include Router, but they also introduce server entry points and deployment concerns, so Start documentation should become the main path for full-stack work.

For devtools specifically, install them only when you want Router inspection. Render them in the root route for the simplest automatic connection, or pass the router instance manually when layout constraints require the panel outside the provider. Keep the default development import for normal local debugging. Use the production import only when you intentionally need the panel in an environment where process.env.NODE_ENV === 'production'. That explicit production import is a signal that devtools are optional developer-facing tooling, not part of the required runtime package set. Sources: docs/router/devtools.md

Next Steps

Continue with the framework-specific quick start when you are choosing your first router adapter. Read the file-based routing and router plugin pages when your next question is how typed route trees are generated. Move to the devtools page when you want screenshots, options, and root-route examples for the debugging panel. If your package decision involves SSR, streaming, server functions, or deployment, use the TanStack Start overview and Start routing pages instead of treating Start as just another client router adapter.