Nova Route Viewer Laravel Package

Technical Evaluation

What changed: 0.1.0 is a requirements-only release. It raises the floor to PHP 8.2+, Laravel 11+, and Nova 5+, and introduces a CI pipeline. There are no new features, no API changes, and no deprecations listed beyond the dropped platform support.

Architecture fit: nova-route-viewer is a Nova tool — a read-only introspection surface that renders the application's registered routes inside the Nova admin panel. Architecturally it is a leaf dependency: it consumes Laravel's route collection and Nova's tool-registration contract, and nothing else in the stack depends on it. That makes fit largely a function of our Nova version, not our application design. It is a developer/operator convenience tool, not a runtime component on any request path.

Integration feasibility: Straightforward if we are already on Nova 5. Nova 5 itself requires Laravel 10+/11 and PHP 8.1+, so this package's Laravel 11+/PHP 8.2+ floor is stricter than Nova's own — meaning a Nova 5 upgrade alone does not guarantee eligibility. Teams on Nova 4 or on Laravel 10 are hard-blocked at 0.0.11 and will receive no further updates.

Technical risk (moderate, well-contained):

• Breaking for anyone below the floor. The jump from 0.0.11 to 0.1.0 is a minor bump under 0.x semver, which conventionally permits breaking changes. Composer constraints of ^0.0.11 will not resolve to 0.1.0 at all, so there is no silent-breakage path — but it also means teams will not be prompted to notice they've been left behind. Pinning is required either way.
• Laravel 11 route bootstrapping is a genuine unknown. Laravel 11 removed the default RouteServiceProvider in favour of bootstrap/app.php and withRouting(). The package reads the route collection, so the question is whether it correctly handles routes registered through the new bootstrap path, deferred providers, and route caching. The release notes assert compatibility but the changelog shows no corresponding code changes — the CI addition may be the only verification.
• Single-maintainer, low-activity project. Small dependency surface and no production runtime exposure keep blast radius low, but bus factor is a real consideration.
• CI is a positive but opaque signal. "Add CI" tells us a pipeline exists; it does not tell us what it runs (test matrix across PHP/Laravel/Nova combinations, static analysis, or just a lint).

Key questions:

1. Does the CI matrix actually exercise Nova 5 against both Laravel 11 and 12, and across PHP 8.2–8.4?
2. Is Nova 4 support truly dropped, or merely untested? If untested, we should treat 0.0.11 as an unsupported fork.
3. Does route discovery work under Laravel 11's bootstrap/app.php routing and under route:cache?
4. What authorization gates the tool? Route introspection exposes internal URL structure, middleware names, and controller class names — acceptable in local/staging, questionable in a production Nova panel.
5. How does the tool behave on large route tables (hundreds to low thousands of routes) — pagination, memory, render time?

Integration Approach

Stack fit: This package is only viable for teams already committed to Nova 5 on Laravel 11+ and PHP 8.2+. Treat it as an optional operator convenience, not a required capability — nothing breaks if it is absent. That framing should drive how much upgrade pressure we let it create.

Migration path:

• On Nova 5 / Laravel 11+ / PHP 8.2+: adopt 0.1.0 directly; replace any ^0.0.x pin.
• On Nova 4 or Laravel 10: hold at 0.0.11 and pin exactly (0.0.11, not ^0.0.11, to avoid surprise resolution if the maintainer backports). Accept that the package is now frozen for us and plan its removal at the next Nova upgrade rather than upgrading the platform for the package.
• On older PHP: this package should not be the thing that forces a PHP 8.2 migration. Sequence the platform upgrade for its own reasons.

Compatibility: Confirm the Nova 5 requirement is a hard composer.json constraint before planning anything; if it is, Composer will resolve correctly and fail loudly, which is the behaviour we want. Also verify the package's extra / tool-registration metadata still matches Nova 5's tool-discovery conventions — Nova tool registration has shifted across major versions and is a common breakage point.

Sequencing:

1. Inventory current PHP / Laravel / Nova versions across all apps using Nova.
2. Upgrade the platform first (PHP 8.2 → Laravel 11 → Nova 5) as an independent initiative.
3. Only then bump nova-route-viewer to 0.1.0.
4. Validate in staging against a route-cached build, not just a local dev server — the cached path is where route-collection edge cases surface.
5. Gate tool registration behind App::environment() so it is not live in production.

Operational Impact

Maintenance: Very low. No runtime dependency, no migrations, no config publication of consequence, no background processes. Ongoing cost is essentially "review releases when the platform moves."

Support: Thin. Single maintainer, small user base, and an issue tracker that is the only escalation path. Mitigate by keeping the tool non-critical and by ensuring no other internal tooling depends on it. Because it is a Nova panel feature, removal is a one-line change — that is the real support story and it is a good one.

Scaling: Not applicable in the request-path sense. The one scaling-adjacent concern is rendering performance on applications with very large route tables; if the tool loads the full collection without pagination, it becomes slow and memory-hungry in exactly the environments (large monoliths) where route debugging is most valuable. Worth a spot check on our largest app before rolling out broadly.

Failure modes:

• Composer resolution failure on the version floor — loud and immediate, the safe failure.
• Silent staleness on Nova 4 — the package stops receiving updates without any signal. This is the most likely real-world failure and it is organisational, not technical. Mitigate with a tracked inventory of pinned packages.
• Incomplete route visibility if Laravel 11 bootstrap-registered routes or deferred providers are missed — the tool appears to work but shows a partial list, which is worse than showing nothing because it erodes trust in the tool.
• Information exposure if enabled in production without an authorization gate.
• Abandonment — if the maintainer stops, the fallback is php artisan route:list from the CLI, which covers the core use case at zero dependency cost.

Ramp-up: Negligible for users — it is a read-only list view inside Nova. For the platform team, the only real work is the version audit and the staging validation against a route-cached build. Budget an hour, not a sprint.