Symfony Route Usage Laravel Package

Technical Evaluation

Headline finding: this is not a Laravel package. symplify/symfony-route-usage targets Symfony's symfony/routing component and its kernel event system. Laravel ships its own router (Illuminate\Routing\Router / RouteCollection) and a middleware pipeline; it consumes several Symfony components (HttpFoundation, Console, Process) but not symfony/routing as its dispatcher. There is no adapter, service provider, or configuration surface for Laravel in this codebase. Treat the name as a category signal ("route usage instrumentation"), not an installable dependency.

Architecture fit

• Core mechanism is a Symfony kernel-event subscriber (kernel.request / console events) that records which routes fire, then diffs the recorded set against the full RouteCollection to surface unused routes.
• Laravel's equivalent hooks are terminate middleware, Route::getRoutes(), and Route::matched() via the router's event dispatcher. The concept transfers cleanly; the code does not. Expect a near-total rewrite of the listener layer, with only the reporting/diff logic being portable.
• Fit score for our stack: low as a dependency, medium as a reference design.

Integration feasibility

• Composer-installable in principle (PHP package), but installing it in a Laravel app yields dead weight: no auto-discovery, no bootable entry point, no Laravel-facing API. Effort to bridge ≈ effort to build native, with a permanent fork liability on top.
• Realistic integration cost if we insisted: 5–10 engineer-days for an adapter plus ongoing divergence tracking, versus an estimated 2–4 engineer-days for a clean Laravel-native implementation.

Technical risk — HIGH

• Deprecated by provenance. The repository lives under deprecated-packages; upstream has explicitly retired it. No security patching, no PHP 8.3/8.4 forward compatibility guarantees, no Symfony 7 or Laravel 11+ support commitment.
• Zero adoption signal. 0 stars and 0 dependents means no field testing, no community bug reports, no third-party writeups, no Stack Overflow corpus. Every defect becomes an internal discovery.
• Constraint drift. Packages of this vintage typically carry pinned PHP/Symfony ranges that will conflict with a modern Laravel composer.json, forcing dependency-resolution hacks (--ignore-platform-reqs, version aliasing) that we would then have to support.
• Abandonment risk compounds silently. A deprecated instrumentation package is exactly the kind of transitive dependency that becomes a security-review blocker two years later when nobody remembers why it is there.

Key questions for the business owner

1. What decision does route-usage data actually drive — dead-endpoint pruning, deprecation tracking, access auditing, or API surface reporting? The answer determines whether a custom middleware is overkill.
2. Do we operate any Symfony services in the portfolio where this is a genuine (if deprecated) option? If yes, that changes the build-vs-adopt math.
3. Are we willing to own a fork indefinitely, including PHP-version upgrades and Symfony/Laravel major bumps?
4. Is the required fidelity per-request (all traffic) or sampled/aggregated (last-N-days)? Sampling dramatically simplifies the design.
5. Is there an existing observability investment (APM, OpenTelemetry, structured request logs) that already answers this question at zero marginal cost?

Integration Approach

Stack fit: Not compatible as-is. The package assumes Symfony's dispatcher and route collection; Laravel's equivalents are structurally similar but API-incompatible. No namespace, config, or container binding overlaps.

Recommended path — build thin, borrow the idea:

1. Discovery (0.5 day). Enumerate Route::getRoutes() at boot; persist route name, URI, method, action, and middleware to a manifest table or JSON artifact.
2. Instrumentation (1 day). Register a global terminate middleware (or a Route::matched() listener) that records route name + method + timestamp into a write-buffered store. Prefer a queued/aggregated write over per-request DB inserts.
3. Reconciliation (0.5 day). A scheduled command diffs the manifest against the observed set and emits "never hit in N days" plus "hit but not in manifest" (catches dynamic/closure routes).
4. Reporting (0.5–1 day). Artisan command output plus a CI gate or scheduled alert. Keep the query surface small — CSV and console table are sufficient for v1.
5. Decommission (0.5 day). Feature flag the middleware; it must be trivially disable-able in production without a deploy if write volume spikes.

Migration path / compatibility: No migration required because there is nothing to migrate from. If a Symfony service later needs parity, the same manifest-and-diff contract can be reimplemented against Symfony's RouterInterface — the data model, not the code, is the reusable asset.

Sequencing: Build the manifest first (valuable standalone as route inventory), then instrumentation, then reporting. Do not block on the reporting UX; route inventory alone typically exposes dead endpoints by inspection.

Alternatives to evaluate before building: framework-level request logging already captured by APM/observability tooling; Laravel Pulse (if already deployed) for request-level visibility; static analysis of route references in views/controllers for the "is this route referenced anywhere" question, which answers most pruning decisions without runtime instrumentation.

Operational Impact

Maintenance. Adopting the package transfers an orphaned codebase to us. Budget a recurring line item for dependency bumps and framework-major upgrades, or accept that it will rot and be ripped out within 18–24 months. A native build is ~200 lines we control and can test.

Support. No upstream maintainers, no issue tracker with activity, no SLAs, no security advisories. Internal self-support only. For a tool that reads production traffic metadata, that means we also own the failure triage.

Scaling. The design pattern (write-on-request) is the part that will hurt at scale, regardless of language. Risks: write amplification on high-RPS endpoints, table growth without a retention policy, lock contention on hot paths. Mitigations: buffer in memory and flush on terminate, sample at a configurable rate, aggregate into per-day rollups, and set a hard retention window (e.g., 30–90 days). Route instrumentation should never sit on a latency-sensitive path unguarded.

Failure modes to design against:

• Route caching. route:cache and closure-based routes can break name resolution or produce unnamed routes — the manifest must tolerate nulls.
• Sub-requests and Octane. Long-lived workers and queued jobs can leak state across requests; the recorder must be request-scoped and reset.
• Noise. 404s, health checks, prefetches, and bot traffic will dominate counts and mask genuinely dead routes — filter by middleware group and status code.
• False "unused" verdicts. Seasonally or quarterly-triggered routes appear dead in a 30-day window. Publish the observation window alongside every report or someone will delete a working endpoint.
• Silent instrumentation loss. If the recorder fails, the report says "everything unused." Fail loudly and stamp the report with coverage metadata (requests observed vs. total).

Ramp-up. Low for the concept, near-zero for the specific package — there is no documentation, no examples, and no community to consult. A mid-level Laravel engineer can implement the recommended native approach in under a week with existing team patterns. The real ramp-up cost is organizational: agreeing on the observation window and on who authorizes route deletion.

Recommendation. Do not add symplify/symfony-route-usage as a dependency. Close it out as a design reference only. Approve a scoped native build (2–4 engineer-days) or, preferably, first confirm whether existing observability tooling already answers the underlying question — in which case the correct decision is to spend nothing.