Route Viewer Laravel Package

Getting Started

Read the constraint before you install anything. Release 0.1.0 requires Nova 5+, Laravel 11+, PHP 8.2+. That is a hard floor, not a suggestion — the release notes for 0.1.0 are literally a compatibility reset. Verify it resolves before you touch NovaServiceProvider:

composer why-not sbine/nova-route-viewer 0.1.0

If that prints a constraint, stop. On Nova 4 or PHP < 8.2 you are pinned to the 0.0.x branch, which is unmaintained.

Pin the exact version. This is pre-1.0, single-maintainer, and the last "minor" bump dropped three whole framework majors. A caret range protects you from nothing:

composer require sbine/nova-route-viewer:0.1.0

Register the tool — that is the whole install. One line in app/Providers/NovaServiceProvider.php:

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

No migrations, no service provider registration, no asset publishing on the common path. It is read-only: it serializes Route::getRoutes() and renders it.

Where to look first: the middleware column. Note that despite the package blurb describing a /route-viewer endpoint usable in "any Laravel application," the shipping artifact is a Nova tool — you reach it through the Nova sidebar, and Nova must be installed. Once in, search by name (dashboard), URI fragment (/api/), or controller namespace (App\Http\Controllers). The column that earns its keep is middleware: "why is auth missing here" and "why does this 404" get answered on one screen instead of an SSH session plus route:list.

Implementation Patterns

Gate it with canSee, not with obscurity. A route inventory is information disclosure — URIs, controller namespaces, middleware names, and internal naming conventions all leak. Subclass and override:

namespace App\Nova\Tools;

use Illuminate\Http\Request;
use Sbine\RouteViewer\RouteViewer;

class GatedRouteViewer extends RouteViewer
{
    public function canSee(Request $request): bool
    {
        return $request->user()?->isAdmin() === true;
    }
}

Register GatedRouteViewer in tools(), and stack the config's access middleware underneath it. canSee hides the nav entry; the middleware blocks the endpoint. Use both.

Pick one production policy and write it down. Either register conditionally, or register everywhere and rely on canSee:

public function tools()
{
    return array_filter([
        ! app()->isProduction() ? new GatedRouteViewer : null,
        // ...other tools
    ]);
}

The failure mode is drift: staging gets the gated subclass, production keeps the base class in a hotfix, and the gate evaporates silently.

Release-gate audits. Before promoting, search the deployed environment for _debug, _ignition, telescope, horizon, and your admin prefixes. This catches the "debug route merged into routes/web.php during a hotfix" incident class — a check, not a convenience.

Trust it to verify the deployed cache, not the repo. Because it reads the registered collection, in a cached environment it shows the cached table. That makes it the fastest way to confirm a deploy actually shipped the routes (or to prove the cache is stale). If it looks wrong, php artisan route:clear and reopen before drawing conclusions.

Separate your surface from vendor noise. Search App\Http\Controllers to isolate your own routes. Search a vendor namespace when auditing a package addition. Search a middleware class name to enumerate every endpoint it touches — the fastest answer to "which routes require EnsureEmailIsVerified?"

Point non-CLI stakeholders at it. QA, support, junior devs, contractors: this decouples "what endpoints exist?" from shell access. That is the actual MTTR win, not the convenience for you.

Pair the UI with a CI artifact. The panel answers "what's live now"; a committed JSON diff answers "what changed":

php artisan route:list --json > storage/ci/routes.json

A PR that alters the routing surface then shows up as a routing change instead of an unremarked side effect.

Gotchas and Tips

^0.0.11 will never resolve to 0.1.0. Composer treats the third segment of 0.0.x as breaking. That's protective (nobody drifts into an untested upgrade) and dangerous (teams silently freeze forever). Tie a reminder to your Nova 5 upgrade.

The version number lies about blast radius. 0.1.0 reads like a patch-level bump and drops Nova 4, Laravel ≤10, and PHP <8.2 outright. Treat every release note as breaking.

Config cache silently no-ops your middleware changes. After publishing config and editing path or middleware, php artisan config:clear locally; in production your edit does nothing until config:cache reruns. "Worked in staging" is usually a missing cache rebuild in the deploy script.

Route cache affects what you see, not what the tool computes. Changed routes without route:clear means the panel shows the old table. Occasionally useful (proving staleness), frequently confusing during debugging.

Large route sets get heavy. Everything is serialized into one payload and filtered client-side — there is no server-side pagination and no config knob for it. Test render and payload against your biggest environment. If it drags, gate the tool out of production rather than trying to tune it.

canSee hides; it does not protect. It removes the nav entry. Anyone who knows the URL still hits the tool route unless the config middleware or conditional registration is also in place. Never canSee on a feature flag and call it a security boundary.

Tool path collisions after Nova upgrades. If you moved the path via config, re-check after each Nova upgrade — Nova's own tool route registration is a known source of silent 404s that look identical to a bug in this package.

Test the gate override before trusting it. A null $request->user() during tool bootstrap or a typo'd role name surfaces as "missing for everyone" or "visible to everyone," and both are easy to miss because the base class still works if you forget to swap the subclass in. One smoke assertion: admin sees it, non-admin doesn't.

Keep route:list documented as the escape hatch. Single maintainer, 57 stars, zero dependents, no SLA. The CI added in 0.1.0 is real hygiene but isn't proof route serialization survives every Nova release. Switching cost is near zero — which is also why adopting it is low risk. Don't build workflows that assume the panel is always present.

Don't let it absorb adjacent scope. It is not request logging, profiling, APM, or an observability layer — that's Telescope and Pulse. It's not frontend route exposure — that's Ziggy. It tells you a route is registered, not that it is fast, correct, or used. Scope creep here is a signal to reconsider the tool, not to extend it.