Route Viewer Laravel Package

Product Decisions This Supports

• Build vs. buy on internal admin tooling. The live decision is whether engineering spends 1–3 days hand-rolling a route-inspection panel into your admin surface, or takes a one-line MIT dependency. At 57 stars and zero dependents, price this as a cheap, reversible experiment — not a platform commitment. Switching cost back to php artisan route:list is near zero, which is precisely what makes saying yes low-risk.
• Nova / admin-surface roadmap scope. If a Nova upgrade or internal ops console is already planned, this is a candidate "free feature" to bundle into that release. The trade-off is now explicit: release 0.1.0 hard-requires Laravel 11+, PHP 8.2+, and Nova 5+, so adoption is contingent on your Nova 5 timeline. Teams on Nova 4 are blocked, not deferred — they'd pin to the unmaintained 0.0.x branch.
• Supportability and MTTR as a budget line. The browsable /route-viewer panel answers "which endpoints exist?", "why is auth missing here?", and "why is this 404?" for QA, support, junior devs, and contractors who cannot shell in to run artisan route:list. That reframes a developer-experience nicety as support-cost reduction with a measurable proxy — time-to-diagnose routing incidents — which survives a budget review far better than "DX."
• Release-gate and security-exposure auditing. A searchable inventory of every registered route (including vendor routes) supports pre-release checks: confirming no _debug, _ignition, Telescope/Horizon, or deprecated admin endpoints are exposed in staging or production. This is a real decision input — but only if access is enforced by policy (canSee plus endpoint middleware), never by "the tool isn't linked in the nav."
• Documentation debt reduction. It replaces the hand-maintained endpoint inventory in the repo or wiki — a recurring maintenance tax most teams under-count and rarely assign an owner to.
• Platform-upgrade forcing function. The new version floor is a citable data point for the Nova 5 / Laravel 11 migration case: the plugin ecosystem is already moving, and staying on Nova 4 means forgoing maintained tooling. A small signal, but a real one.
• Explicitly not supported — protect the boundary. It is not observability or APM, not a route-performance profiler, not request logging, and not a frontend route helper (that's Ziggy). Do not let it absorb budget or scope from Telescope, Pulse, or a profiling decision. It tells you routes are registered — not that they're fast, correct, or used.

When to Consider This Package

Adopt when all of the following hold:

• You already run Laravel Nova 5 in the relevant environments and are comfortable owning that commercial dependency. Without Nova — or on Nova 4 and below — the current release line delivers zero value.
• Your stack meets the 0.1.0 floors: Laravel 11+, PHP 8.2+, Nova 5+. Older stacks must pin to 0.0.x, now effectively an unmaintained branch; budget the platform upgrade first or don't adopt.
• You have non-CLI stakeholders — support, QA, junior developers, agency contractors — who regularly need route information and currently interrupt an engineer with shell access to get it.
• You need a read-only, low-blast-radius diagnostic: no migrations, no writes, no footprint on the application request path. It only walks Route::getRoutes() and renders what the router already knows.
• You can absorb single-maintainer, low-adoption risk (57 stars, zero dependents, no SLA). The CI added in 0.1.0 is a genuine maturity signal, but it is a build/smoke check — not a community backstop or evidence of scale-tested use.
• You accept that this is pre-1.0. 0.1.0 is a compatibility reset, not an API-stability promise; pin an exact version (0.1.0, not ^0.1.0) and treat every release note as potentially breaking.
• You can gate it deliberately per environment and document which pattern you chose — registered everywhere behind canSee + middleware, or registered only in non-production. The failure mode is drifting between the two, so the gate silently disappears in production.

Look elsewhere when:

• No Nova license, or still on Nova 4 / Laravel ≤10 / PHP <8.2. There is no supported path today; the legacy branch is frozen.
• You need observability, profiling, or route-performance data. That's Telescope, Pulse, or an APM — different budget, different owner.
• You need guarantees. Zero dependents plus a single maintainer means no ecosystem backstop; if your compliance posture requires a supported dependency with an SLA, this fails that bar regardless of how good the UI is.
• Your route tables are very large. All routes are serialized into one payload and filtered client-side with no server-side pagination. Validate render and payload against your biggest environment before promoting; if it lags, gate to non-production rather than trying to tune it.
• You'd have to upgrade the platform solely for this. The tool does not justify a Nova 5 migration on its own; it should ride an upgrade that's already funded.

How to Pitch It (Stakeholders)

For executives / sponsors (30 seconds): "A one-line, MIT-licensed, read-only panel that shows every registered route in our admin console — no custom build, no maintenance burden. It removes a routine engineering interruption: today anyone who needs to know what endpoints exist has to find an engineer with server access. It also gives us a cheap pre-release check that we haven't shipped a debug or admin route by accident. Cost is effectively zero and we can remove it in minutes if it doesn't earn its place. The one caveat is that we need to be on the current Laravel/Nova generation (Laravel 11+, PHP 8.2+, Nova 5+) — so this rides the upgrade that's already on the roadmap, it doesn't create a new one."

For engineering: "Install, register the tool in NovaServiceProvider::tools(), ship. No migrations, no asset pipeline changes, no request-path overhead — it reads the router's registered collection. Two things are non-negotiable before it goes anywhere near production: (1) a canSee override plus the config's access middleware, because route inventory is information disclosure — controller namespaces and middleware names leak our auth strategy and architecture; and (2) pin the exact version, because ^0.0.11 will never float to 0.1.0 and 0.1.0 reads like a minor bump but drops Nova 4, Laravel ≤10, and PHP <8.2 outright. Keep php artisan route:list documented as the escape hatch. One operational nuance worth internalizing: what the panel shows is the cached route table, so it's excellent for confirming a stale deploy cache during an incident — and misleading if you forget to route:clear first."

The framing that lands: it's not a developer toy, it's a support-cost reduction and a release-gate check that happens to cost one line and one dependency. The risk is bounded and reversible; the value is decoupling a routine question from shell access.