Route Viewer Laravel Package

Technical Evaluation

Architecture fit. sbine/route-viewer is a thin, read-only Nova tool. It walks Laravel's already-populated route collection (Route::getRoutes()) and renders it as a searchable table — it does not intercept requests, register middleware on the app's request path, add migrations, or own any persistent state. For a TPM this is the ideal risk profile for a diagnostic utility: the integration surface is a single entry in NovaServiceProvider::tools(), and the blast radius of a failure is confined to one Nova screen. It has no architectural opinion about your application and no coupling to domain code. That means it does not need to be evaluated as a platform component — it should be evaluated as an internal tooling dependency with a near-zero switching cost.

Integration feasibility. The hard gate is the 0.1.0 version floor: Laravel 11+, PHP 8.2+, Nova 5+. This is the single most important fact for planning. Teams on Nova 4 or PHP 8.1 are not "slightly behind" — they are pinned to the unmaintained 0.0.x branch and Composer will not float them forward (^0.0.11 cannot resolve to 0.1.0). Feasibility is therefore a function of your existing Nova upgrade timeline, not of this package's complexity. Where the floor is met, install is a one-line composer require plus a one-line provider registration, with an optional config publish if you need to relocate the path or add access middleware. The verification step is a single command — composer why-not sbine/nova-route-viewer 0.1.0 — which a TPM can ask for as a concrete pre-adoption gate.

Technical risk. Three risks matter, in descending order:

1. Information disclosure. The tool exposes URIs, controller namespaces, named routes, and middleware names. That is a map of your auth strategy and application architecture. "It's not linked in the nav" is not a control. The mitigation is explicit and cheap: override canSee in a subclass, stack the config's access middleware, and decide per-environment whether the tool is registered at all. A TPM should treat a missing canSee override as a ship blocker, because it is a security posture decision disguised as a UX one.
2. Pre-1.0 semantics and single-maintainer risk. 57 stars, zero dependents, one maintainer, no SLA. The 0.1.0 release note is instructive: a version bump that reads as minor dropped Nova 4, Laravel ≤10, and PHP <8.2 entirely. Minor-number semantics do not hold here. Pin exact versions and treat every release note as potentially breaking. The CI added in 0.1.0 is a genuine maturity signal but not a community backstop.
3. Stale-view confusion. Because the tool reads the registered (often cached) route table, it can confidently display a route set that no longer matches the code. This is occasionally a feature during incident response and frequently a debugging trap. Document the route:clear prerequisite.

Key questions to resolve before committing.

• Are we on Nova 5 / Laravel 11 / PHP 8.2 in every environment where we intend to use this?
• Who owns the canSee override, and what is the policy (role? admin flag? environment)?
• Is the tool registered in production, or non-production only? Pick one and document it — drifting between environments is the dominant failure mode.
• What is our route-table size on the largest environment, and does the single-payload/client-side-filtered render hold up?
• Do we have a named owner for the Nova 5 upgrade, given that this package's floors now make that upgrade a prerequisite for maintained tooling?

Integration Approach

Stack fit. The package assumes a Laravel + Nova stack and nothing else. It will not fit a team using an alternative admin surface (Filament, Backpack, custom Blade admin) — in those cases the php artisan route:list CLI or a small custom panel is the comparable option, and the switching cost between them is low enough that this is not a strategic decision either way. The fit question is really "do we run Nova, and do we want route inventory inside it?" rather than "does this compose with our architecture?"

Migration path. There is no migration — no schema, no data backfill, no config bootstrapping on the common path. The only code change is adding the tool to NovaServiceProvider::tools(). Rollback is removal of that line plus composer remove. This is why the correct framing for a TPM is reversible experiment, not adoption program. Budget it as a cheap trial with a defined evaluation window (e.g. one release cycle) and a stated criterion for keeping it: measurable reduction in "which endpoint handles X?" escalations to engineers.

Compatibility. Two compatibility axes to plan around:

• Framework floors as described above — this is a hard gate, not a soft one.
• Nova's own tool-route registration, which is a known source of silent 404s on tool UIs after Nova upgrades, particularly if you relocated the path via config. Add "does the Route Viewer screen still load?" to the Nova-upgrade checklist. It is a two-second check and it is the check most likely to be skipped.

Sequencing. The dependency-aware order of operations:

1. Confirm floors via composer why-not; if blocked, park the package and attach it to the Nova 5 upgrade epic rather than tracking it separately.
2. Install pinned to an exact version (:0.1.0), not a caret range.
3. Land the canSee subclass and access middleware in the same PR as registration — never register first and gate later, because "later" is where the exposure incident lives.
4. Decide production exposure and encode the decision in code (array_filter on app()->isProduction() or an equivalent), not in a runbook.
5. Add the smoke assertion: admin sees the tool, non-admin does not.
6. Only then broaden access to support/QA and announce it as a self-service path.

Pairing with CI. The UI answers "what is live now"; a committed php artisan route:list --json artifact answers "what changed in this PR." These are complementary, not redundant. If you want routing changes to be reviewable diffs, the CI artifact is the durable mechanism and the Nova panel is the human-facing convenience.

Operational Impact

Maintenance. The maintenance load is near-zero in steady state and spiky at upgrade boundaries. No migrations, no background jobs, no queue interaction, no scheduled tasks. The recurring costs are: tracking release notes (mandatory — see the 0.1.0 lesson), re-verifying the tool UI after Nova upgrades, and re-checking config cache behavior after any path or middleware change. Assign one owner. An unowned dependency with an unmaintained fallback branch is how teams discover eighteen months later that they are frozen on 0.0.11.

Support. This is the section where the TPM case is strongest. The package's real product value is decoupling a routine question from shell access. Support engineers, QA, junior developers, and agency contractors currently cannot answer "what endpoints exist?", "why is this route 404?", or "which routes require EnsureEmailIsVerified?" without interrupting an engineer with environment access. That is a recurring interrupt tax with a measurable proxy: time-to-diagnose routing incidents. Framing the spend as support-cost reduction rather than developer-experience nicety is both more accurate and easier to defend in a budget review. It also retires a hand-maintained endpoint inventory in the wiki — a documentation debt item most teams carry without an assigned owner.

Scaling. One known limit: all routes are serialized into a single payload and filtered client-side, with no server-side pagination and no pagination config. On a small app this is invisible; on a large app with many vendor packages registered (Telescope, Horizon, Nova itself, Sanctum), render and payload size should be tested against your biggest environment before you promote the tool broadly. If it lags, the correct response is to gate the tool to non-production — there is nothing to tune. Plan for this as a known ceiling rather than a surprise. A secondary scale concern is organizational, not technical: broadening access to the tool widens the audience for the information it discloses, which is why the canSee decision must precede the rollout decision.

Failure modes. Enumerated, with the operational response for each:

• Tool silently missing for everyone, or visible to everyone. Caused by a misconfigured canSee override (null user during tool bootstrap, role-name typo) or by forgetting to swap the subclass in. Detect with the smoke assertion; this is the most likely failure and the easiest to miss because the base class keeps working.
• Endpoint reachable despite canSee. canSee hides the nav entry; it does not by itself remove the route. Requires the config's access middleware as the second layer, plus conditional registration as a third if you want belt-and-suspenders.
• Stale route table. The panel shows the cached table, not the code. After route changes, route:clear before trusting the view. During incidents, this doubles as a fast way to confirm whether a deploy picked up route changes — a genuine diagnostic feature if the team knows to expect it.
• Config changes that are silently no-ops in production. Editing path or middleware without rebuilding config:cache means staging "worked" while prod diverges. Put config:cache in the deploy script and verify it.
• Silent 404 on the tool's own UI after a Nova upgrade, particularly after a path relocation. Indistinguishable from a tool bug at first glance.
• Stale pin on the unmaintained branch. ^0.0.11 will never float to 0.1.0 by design. Add a calendar reminder tied to the Nova 5 / Laravel 11 upgrade so the freeze is a decision rather than an accident.

Ramp-up. Effectively zero for end users — it is a search box over a table, and the highest-value column in daily use is middleware. Ramp-up cost sits with the implementing engineer, and it is small but non-trivial: writing the canSee subclass, deciding environment exposure, and adding one smoke test. Call it half a day including review, not the "one-line install" the marketing implies. The escape hatch — php artisan route:list — should stay documented, because a team that has forgotten how to inspect routes without the panel has coupled itself to a single-maintainer pre-1.0 dependency for a routine operational capability.

Scope discipline. This is read-only route inventory. It is not request logging, profiling, or observability (Telescope, Pulse), not frontend route exposure (Ziggy), and it does not tell you whether routes are fast, correct, or used. If the roadmap conversation starts bending it toward any of those, that is a signal to reconsider the tool, not to extend it — and a signal to protect the adjacent observability budget from being quietly reallocated to a Nova panel.