next dev — Built-in Route Inspector Panel (Visual Debugging for App Router)

[Saobia3i]

Goals

1. Give developers a visual overview of the full App Router route tree during development
2. Show rendering strategy (Static / Dynamic / PPR) for each route at a glance
3. Display which special files (loading, error, not-found) exist per route and where middleware applies

Non-Goals

1. This is NOT a production feature dev mode only, zero impact on build output
2. Not meant to replace React DevTools or browser network inspector
3. Not a route testing or benchmarking tool

Background

Nuxt has DevTools with a built-in route explorer. Remix has a route visualizer in their playground. Next.js has no equivalent today.

As the App Router has grown more powerful with nested layouts, parallel routes, intercepting routes, route groups, and middleware it has become genuinely hard to understand the routing tree of a large project at a glance. Developers must mentally reconstruct it by browsing the file system, which causes confusion and longer onboarding time for new contributors.

Current alternatives like manually reading the /app folder or using third-party tools are not ideal and don't integrate with Next.js internals (rendering strategy, PPR, middleware scope).

Proposal

Add a built-in Route Inspector Panel accessible only in next dev mode, toggled via a keyboard shortcut (e.g. Ctrl+Shift+R) or a dev-only URL like /_next/routes.

It would display a tree like:

/
├── layout.tsx [Root Layout]
├── page.tsx [Static]
├── dashboard/
│ ├── layout.tsx [Dashboard Layout]
│ ├── page.tsx [Dynamic]
│ ├── loading.tsx ✓
│ └── settings/
│ └── page.tsx [PPR]
├── @modal/ [Parallel Route]
│ └── login/
│ └── page.tsx
└── middleware.ts → applies to: /dashboard/*

Next.js already parses the file system at dev startup, so the data needed for this panel is already available internally no new scanning logic required. This would be a low-risk, high-value DX improvement. I am interested in contributing a prototype if the core team is open to it.

[angel-cm-dev]

This is a much-needed feature for the Next.js ecosystem. As applications grow in complexity—leveraging Parallel Routes (@modal), Intercepting Routes (.), and Middleware—the mental model of the route tree becomes increasingly difficult to manage.

From a Developer Experience (DX) and Performance perspective, having a visual dashboard would solve three major pain points:

1. Rendering Strategy Visibility: Instantly identifying which segments are Static, Dynamic, or using PPR without checking the build logs or code constants. This is crucial for optimizing Core Web Vitals during development.
2. Middleware Scoping: Visualizing the "impact zone" of middleware.ts across the route tree to avoid unintended side effects on specific route groups.
3. Special File Debugging: Ensuring that loading.tsx, error.tsx, and not-found.tsx are correctly placed and active for the intended segments.

Nuxt DevTools has set a high bar for this, and seeing a native implementation in Next.js would significantly lower the barrier for new contributors and speed up debugging in enterprise-scale projects. I'd love to see this integrated into the existing Next.js Dev Overlay! 🚀

[selcukcukur]

@Saobia3i This is a really thoughtful proposal — and you’ve articulated the pain point well. As the App Router has grown more complex, it’s genuinely hard to visualize nested layouts, parallel routes, intercepting routes, and middleware scopes without mentally reconstructing the file tree.

A built‑in Route Inspector Panel in next dev would solve several developer experience gaps:

• Visual overview: Developers could instantly see the full route tree, rather than piecing it together from the /app folder.
• Rendering strategy clarity: Showing Static / Dynamic / PPR at a glance would help teams understand performance implications without digging into build logs.
• Special files and middleware: Surfacing loading.tsx, error.tsx, not-found.tsx, and middleware scopes directly in the tree would reduce onboarding friction and debugging time.

The fact that Next.js already parses the file system at dev startup means the data is available — it’s more about exposing it in a developer‑friendly UI. Other frameworks (Nuxt DevTools, Remix playground) have proven the value of this kind of visualization, so there’s precedent.

Guidance for contribution

• DX‑only scope: Keeping it strictly in next dev mode ensures zero production impact.
• Integration point: A dev‑only route like /_next/routes or a keyboard shortcut is consistent with existing Next.js tooling.
• Prototype path: Start with a simple tree view (like your example), then iterate to add rendering strategy and middleware visualization.

If you’re interested in contributing, the best next step would be to open a GitHub issue or RFC draft in the Next.js repo, referencing your prototype idea. The core team usually encourages DX improvements, especially if they’re opt‑in and dev‑only.