Routes Explorer Laravel Package

Product Decisions This Supports

• Route inventory as a first-class artifact. Gives the team a browsable view of every registered endpoint (URI, method, controller/action, name, middleware) instead of a scrolling php artisan route:list dump. This directly supports release-readiness reviews where someone must confirm "what did we actually ship?"
• API surface audit before a major release. Enumerate public endpoints to spot orphaned routes, duplicated handlers, debug/test routes left registered, or endpoints missing auth/throttle middleware — the kind of finding that becomes a security ticket rather than a post-incident retro.
• Deprecation and sunset planning. A complete route list is the prerequisite for a credible v2 API plan: you cannot commit to breaking changes without knowing the full surface you are breaking.
• Build vs. buy (vs. don't build). This is a candidate answer to "should we build an internal route-catalog/admin view?" It is MIT, dev-only, and disposable, so it can be evaluated as a spike rather than a platform bet. The realistic comparison set is not another package but php artisan route:list --json piped into a trivial internal Blade view — a ~1 day job. That framing is the actual decision: adopt, replicate, or skip.
• Onboarding velocity. New engineers get a self-serve map of the application, reducing the "ask a senior dev which controller handles this URL" tax during their first weeks.
• Documentation pipeline input. If the roadmap includes generated API docs, this package can inform the decision but is unlikely to be the generator — treat it as evidence-gathering, not the chosen tool.

When to Consider This Package

Consider it when all of the following hold:

• The app is a small-to-mid Laravel monolith with a route count a human can reason about (roughly low hundreds, not thousands).
• The team is on a Laravel version contemporaneous with the last release (2022-02-22, i.e. the Laravel 8/9 era) or is willing to spend the spike time verifying it boots on the current major. Compatibility with Laravel 10/11/12 is unverified and is the single largest adoption risk.
• Usage is strictly require-dev, local or staging, gated behind auth middleware or APP_ENV checks. This must never appear in a production dependency graph.
• The need is exploratory and human-facing: "let me look at our routes," not "export routes to CI."

Look elsewhere — or build the 1-day internal equivalent — when:

• You need maintained dependencies with a security policy. Last release is over three years old, stars are low (39), and dependents are zero, which is the clearest signal available: no one in the ecosystem has validated this on a real production codebase.
• You need programmatic or CI-integrated output. Prefer artisan route:list --json (first-party, always compatible, scriptable) as the contract, then render whatever UI you want on top.
• You need OpenAPI/Swagger generation. Use a maintained, purpose-built generator; this package's value is visibility, not specification output.
• You need route-level traffic, latency, or error data. That is APM/Telescope territory — an explorer shows what could be called, never what was called.
• The route count is large or the app is modular/multi-tenant, where a static list stops being navigable.
• Single-maintainer risk is disqualifying for your org's OSS intake policy.

How to Pitch It (Stakeholders)

To executives: This is a free, MIT-licensed developer convenience for Laravel teams — a visual directory of the application's URLs. It costs roughly one engineer-day to evaluate and carries no production risk because it is installed only in development environments. The strategic value is narrow but real: it makes it cheap to answer "what endpoints do we expose?" ahead of a release, a security review, or an API versioning decision. It is not a platform investment: the project has 39 GitHub stars, no downstream dependents, and no release since February 2022, so I recommend we timebox a spike and keep the first-party route:list --json command as our durable fallback rather than standardizing on it.

To engineering: Proposal is a 1-day spike, not an adoption. Install with --dev, confirm it boots on our current Laravel version, and check it against our real route table — the exit criterion is whether it surfaces anything route:list doesn't, cleanly. Two hard rules: never in composer.json require (dev only), and never reachable in production. If it fails to install or looks abandoned on inspection, we stop and spend the day writing a thin internal view over artisan route:list --json, which gives us the same visibility with zero third-party risk and full control over filtering and middleware display. Success looks like a route-inventory artifact we can reuse in release checklists and onboarding docs; the package itself is incidental to that outcome.