Symfony Route Usage Laravel Package

Product Decisions This Supports

• Dead-route cleanup as a scoped initiative. Turns "we probably have unused endpoints" into a ranked list of candidate routes with observed traffic (or lack of it), so a cleanup epic gets sized and prioritized against other maintenance work instead of being an open-ended chore.
• Deprecation and sunset calls. Before removing a legacy API surface, retiring a feature flag, or telling a partner integration is EOL, gives evidence about which routes are still being hit — the difference between a deprecation notice and a hard cut.
• Migration scoping (framework upgrades, monolith-to-service splits, URL restructuring). Routes with zero observed traffic don't need to be ported, tested, or documented in the new world. Directly reduces migration surface and QA scope.
• Security and compliance review inputs. An unused route is still a reachable endpoint with an auth model and a payload parser. Output feeds WAF allowlisting, endpoint inventory for audits, and attack-surface reduction arguments.
• Build vs. buy — and here the answer is build. At Score 0, zero listed dependents, and a home under deprecated-packages, this is not an adoptable dependency. It is a reference implementation of a thin pattern (a kernel.request listener that records the matched _route, plus a report command). Treat it as a design sketch to reimplement in-house in a day or two, dev-only, with an expiry date — not as a vendor choice.
• Internal engineering-effectiveness lever, not a roadmap differentiator. Nothing here ships to customers. Frame it as maintainability and cost-of-ownership reduction, and be honest that's how it should be judged.

When to Consider This Package

Consider the approach (not the package as a dependency) when:

• The application is Symfony — this is a Symfony bundle. If the team is on Laravel, stop: the equivalent is a middleware recording $request->route()->getName() plus php artisan route:list as the inventory. Forcing this package into a Laravel codebase is a non-starter.
• The route count is large enough that manual review is unreliable — roughly hundreds of routes, or a codebase with years of accumulated controllers and legacy prefixes.
• You want a quick, low-effort read on route utilization before committing to a bigger cleanup or migration program, and you're willing to run it as a time-boxed spike.

Look elsewhere (or build) when:

• Maintenance and support matter. Repository is archived under deprecated-packages, zero stars, zero dependents. No security response, no compatibility guarantee for current Symfony versions, no issue triage. Any use must be pinned, dev-only, and short-lived — or vendored and owned.
• You need production-grade coverage. Sampling instrumentation on a live app misses low-traffic routes. A route unseen for 30 days is not dead: cron jobs, webhooks, monthly partner integrations, seasonal endpoints, and admin tools all hide from short windows. This class of tool produces false "unused" verdicts and must never be the sole basis for deletion.
• You already have telemetry. Access logs, load balancer metrics, or APM traces can be mapped path→route with zero new dependencies and full historical coverage. That is strictly better evidence than an instrumented probe you just turned on.
• Static detection is sufficient. Grepping templates and path()/url() call sites, plus a PHPStan or Rector rule for orphaned route names, catches a meaningful share without touching runtime at all.

Adoption gate to write down before anyone starts: Symfony-only, dev/staging plus a sampled canary in production, observation window covering at least one full business cycle, and a named owner for the in-house fork.

How to Pitch It (Stakeholders)

For executives (one paragraph): We can shrink the surface area we maintain — fewer live endpoints to secure, monitor, test, and carry through framework upgrades. The output is a ranked list of routes worth retiring, backed by traffic evidence. Cost is small: the open-source package itself is archived and unmaintained, so we would not take a dependency on it — we'd reimplement the same ~200-line pattern in-house in about a day. Benefit is reduced maintenance and security-review burden, not new revenue; judge it as a cost-reduction and risk-reduction play.

For engineering (the actual ask): Do not add symplify/symfony-route-usage as a dependency — it's deprecated, has no users, and won't track current Symfony releases. Take the pattern: a lightweight kernel.request listener that records route name and timestamp for a bounded window, a console command that diffs observed routes against debug:router output, and a hard feature flag plus expiry so it never becomes permanent production scaffolding. Run it in staging continuously and in production behind sampling.

Say the caveat out loud in the room: "Unused" from a short observation window is a hypothesis, not a fact. We commit to a full business cycle of evidence, cross-checked against logs or APM, and a redirect/deprecation period before any route is removed.