Symfony Route Usage Laravel Package

Product Decisions This Supports

• Dead-code and dead-endpoint retirement. Route-usage telemetry turns "I think nobody calls this" into evidence. That directly supports roadmap decisions like "can we delete the v1 API surface this quarter?" and "is this legacy module still earning its maintenance cost?"
• Attack-surface reduction as a security deliverable. Unused routes are still live endpoints. A usage audit lets you argue for removal on risk grounds, not just tidiness — a much easier business case to fund.
• Deprecation and versioning policy. Before committing to a v2 with a sunset date for v1, you need per-route call data. This is the input to a credible deprecation calendar and customer comms plan.
• Migration sequencing. When consolidating frameworks, services, or monolith→service boundaries, used-vs-unused routes tell you what actually has to be ported and what can be dropped rather than rewritten. That is a scoping decision with direct budget impact.
• Build vs. buy vs. skip. This is the clearest decision the package informs: the capability (route usage instrumentation) is worth having; this specific artifact is not the way to get it (see below). Useful as a reference implementation and a vocabulary for the requirement, not as a dependency.
• Prioritizing observability investment. If usage data is only available via a one-off audit, that's a signal to fund continuous route-level telemetry; if audits suffice, don't build a platform for it.

Important framing for the decision record: despite being scoped here as a Laravel/PHP package, this is a Symfony package (Symfony routing/kernel), and it lives in a deprecated-packages organization with zero stars and zero dependents. For a Laravel codebase it is not adoptable — the routing, middleware, and kernel models differ. Treat this as market signal that the problem is real and small, and treat the solution as a ~1-day in-house middleware spike.

When to Consider This Package

Consider the capability (not necessarily this package) when:

• You have a large, aging route table — typically hundreds of endpoints accumulated across teams and years — and no reliable per-route traffic data.
• You are planning a deprecation, a version sunset, a framework migration, or an API surface consolidation and need evidence rather than intuition.
• You have a compliance or security requirement to enumerate and justify every exposed endpoint.
• You need a one-off audit and can run it in a non-production or shadow environment.

Look elsewhere — or build instead — when:

• The codebase is Laravel. This package targets Symfony; the routing and middleware primitives don't map. Build a route-logging middleware instead, or use an actively maintained Laravel route-statistics middleware package. Either way, evaluate maintenance status first.
• You need a production dependency with a support story. Zero stars, zero dependents, and an archived home mean no security patches, no compatibility guarantees, and no one to escalate to. That is disqualifying for anything on the critical path.
• You need continuous telemetry, not a snapshot. Sampling, cardinality control, PII handling in path parameters, retention, and dashboards are product requirements this package does not attempt to meet.
• You need multi-tenant or per-customer usage attribution. "Route X is unused" is very different from "Route X is unused by all but one enterprise account" — the latter is a revenue conversation, not a deletion. Verify the tool can distinguish them before you promise a cleanup.
• You have a hard SLA or audit regime where the tooling itself must be documented and maintained.

Decision rule: adopt the pattern, not the package. Write the smallest thing that logs route name, method, status, and caller identity to a queryable store; run it for 30 days; then make the deletion decision. Cheaper than a dependency risk review, and you own the schema.

How to Pitch It (Stakeholders)

To executives (one paragraph): We have a cheap opportunity to shrink our API surface and reduce maintenance and security exposure. Today we can't confidently answer "which endpoints does anyone actually use?" — so we keep everything, and we pay for it in maintenance, testing, and attack surface. Instrumenting route usage for 30 days gives us a defensible list of candidates to retire, and a credible deprecation calendar for versioned APIs. Cost is small and bounded (roughly one engineer-day plus a month of observation); the payoff is a smaller surface to secure and migrate. Recommendation: build the instrumentation in-house rather than adopt the package under review — it's a deprecated, zero-adoption Symfony library that doesn't fit our Laravel stack, so it's useful as a design reference and problem validation only.

To engineering (the honest version): The package detects used and unused Symfony routes — a genuinely useful idea, well-aligned with our cleanup goals, but it's archived, unmaintained, has no dependents, and doesn't target Laravel. Do not add it as a dependency. Instead, implement equivalent instrumentation as a global middleware: log route name, method, response status, and a caller identifier; avoid raw path parameters (PII and cardinality); sample if volume demands it; aggregate into a weekly report. Then we use that report to drive route removal tickets. Flag two things before we commit: per-tenant attribution (one customer using a "dead" route is a breaking change, not a cleanup), and a documented review step so "unused" isn't treated as automatically safe to delete.