Nova Route Viewer Laravel Package

Getting Started

Version 0.1.0 is primarily a platform floor bump, not a feature release — plan for it before you plan around it.

Requirements as of 0.1.0:

• PHP 8.2+
• Laravel 11+
• Laravel Nova 5+

If you are on Nova 4, Laravel 10, or PHP 8.1, stay on 0.0.11 and pin it explicitly:

composer require "sbine/nova-route-viewer:0.0.11"

On a Nova 5 stack, install normally:

composer require sbine/nova-route-viewer

Then register the tool in app/Providers/NovaServiceProvider.php:

public function tools()
{
    return [
        // ...
        \Sbine\RouteViewer\RouteViewer::make(),
    ];
}

First use case: open the Nova sidebar, hit the Routes entry, and use it as php artisan route:list for people who should not have SSH access — support engineers, product owners, QA — to confirm a route exists, see its URI/name, and check which controller and middleware stack handles it without you pasting terminal output into Slack.

Where to look first after install:

1. The Nova sidebar entry (confirms the tool booted).
2. Your routes/*.php and any service providers calling Route:: at runtime — those show up here, which is often the point.
3. composer show sbine/nova-route-viewer to confirm you actually resolved 0.1.0 and not a cached older lock entry.

Implementation Patterns

Treat it as a read-only introspection surface. It is a viewer, not a router manager. Do not design workflows that expect to edit, disable, or re-order routes from the UI.

Use it as the first stop in route-debugging triage. When a 404 or a wrong-controller bug lands, the sequence is: Nova → Routes → search the URI → confirm the name, verb, action, and middleware. This is faster than route:list | grep on a locked-down staging box and gives non-terminal users the same answer.

Pair it with your environment matrix. Because route registration is conditional (if (app()->isProduction()), feature flags, Route::domain()), the same route may exist locally and not in staging. Having the viewer available in staging/QA Nova environments turns "works on my machine" into a concrete diff. Install it in every Nova-guarded non-production environment; be deliberate about production.

Keep it behind Nova's own auth. The tool lives inside Nova, so access is already gated by your NovaServiceProvider::gate() / Nova authorization. That is the whole security model — do not additionally expose it via a custom route or a public dashboard. If you need finer control (e.g. only admin sees routes), express it through Nova's authorization callbacks rather than forking the tool.

Upgrade path for existing installs. Because this is a 0.0.x → 0.1.0 bump, expect composer update to refuse on older platforms rather than silently downgrade. Sequence: bump PHP runtime in CI and containers → bump Laravel to 11 → bump Nova to 5 → then composer require sbine/nova-route-viewer:^0.1. Doing Nova last-but-one avoids a half-migrated toolchain where Nova 4 is still pinned and the constraint simply cannot resolve.

CI note. 0.1.0 adds CI to the package itself. That is a signal about maintainer hygiene (the constraint matrix is now exercised), not a runtime feature. It slightly raises confidence that the Laravel 11 / Nova 5 combination is actually tested rather than merely declared — but it does not change your integration surface.

Gotchas and Tips

The version bump is the breaking change. 0.0.11 → 0.1.0 under semver-for-0.x means "may break." Here the break is purely the requirement floor, but Composer will still hard-fail resolution — the error surfaces as a confusing "does not match your requirements" wall, not as a friendly "upgrade Nova." Read the constraint before assuming a package bug.

Nova 5 is a paid, licensed dependency. You cannot install or test this in CI without Nova credentials. Keep the tool out of any pipeline that does a bare composer install without a Nova auth config, or your build breaks for reasons unrelated to the route viewer.

Route caching changes what you see. php artisan route:cache bakes routes; closure-based routes will fail to cache entirely and many dynamic registrations behave differently cached vs. uncached. If the viewer shows a route that 404s, or omits one that exists, check bootstrap/cache/routes-v*-*.php existence and run php artisan route:clear before filing anything.

Closure routes have no controller to show. Rows backed by function () { ... } render with a closure action, which is not useful for navigation and cannot be route-cached. If the viewer is being used to audit your routing surface, treat a wall of closures as a code smell worth fixing independently.

Middleware display is the highest-value column — read it as a stack, not a list. Order matters; a route showing web but missing your auth or tenant-scope middleware is exactly the misconfiguration this tool surfaces fastest.

It is a viewer at 0.x. With a single-digit minor and a long gap from 0.0.11, treat the API as unstable and avoid patching the package in place or subclassing its internals. If you need customization, prefer a thin fork pinned to a commit over subclassing, and record the pin in your upgrade notes.

Extension points are intentionally thin. There is no meaningful hook surface to build on — no custom columns, no per-environment toggles, no exporter. If you need route data programmatically (dashboards, drift detection between environments), use app('router')->getRoutes() directly rather than trying to extract data from this tool.

Debug checklist when the menu item does not appear: tool registered in tools() (not dashboards()), php artisan nova:publish / asset rebuild run if you upgraded Nova in the same window, php artisan optimize:clear, and confirm the resolved version is actually 0.1.0 — a stale composer.lock still on 0.0.11 looks identical in the UI.