Symfony Route Usage Laravel Package

Technical Evaluation

Architecture fit — poor as a direct dependency. migrify/symfony-route-usage is a Symfony Bundle. It expects Symfony's Kernel, RouteCollection, DI container extension registration, and event dispatcher. Laravel exposes Illuminate\Routing\RouteCollection and a middleware pipeline with no bundle/container-extension analogue. There is no adapter path — it cannot be installed into a Laravel app and "just work."

Mechanism (as inferred). The package detects used vs. unused routes by instrumenting request handling and persisting route hits to storage, then diffing observed routes against the registered route table. That model is sound and portable in principle; only the implementation is Symfony-bound.

Integration feasibility — low for this artifact, high for the concept. The realistic options are: (1) port the concept to Laravel middleware, (2) adopt a Laravel-native equivalent (e.g. spatie/laravel-route-usage, which implements the same idea on Laravel's pipeline), or (3) run this package only in Symfony services that remain in the fleet, and align reporting across both.

Technical risk — high. The repo sits under deprecated-packages/, has 0 stars, 0 dependents, and a composite score of 0. That means no CVE pipeline, no Symfony 6/7 compatibility work, no bug triage, and unknown PHP version bounds. It is effectively source-available reference code, not a maintained dependency. The only durable option is to fork and own it.

Key questions for the vendor/owner

• What is the detection mechanism — runtime listener, profiler collector, or access-log parsing? (Determines whether sampling and retention are feasible.)
• What storage backend and schema does it assume, and what is the per-request write cost?
• How does it treat parameterized/dynamic routes, API routes, and console/queue-invoked routes?
• Licence terms, and whether an internal fork is permitted without upstream notice.
• Symfony version constraints and PHP floor — is it already incompatible with our runtime?

Integration Approach

Stack fit. Treat this repository as a design reference, not a dependency. For the Laravel estate, implement the same capability natively: enumerate routes via Route::getRoutes(), attach a terminal middleware that records route.getName() (or the URI pattern) into a bucketed store, and periodically reconcile the observed set against the registered set. Aggregate per route per day rather than per request.

Migration path. Two tracks in parallel:

1. Laravel services — adopt or build the Laravel-native equivalent; no Symfony code crosses over.
2. Residual Symfony services — if any exist, evaluate this package there as a short-lived analysis tool in a non-production environment only, accepting it is unmaintained.

If both tracks run, converge on a shared reporting schema (route identifier, service, hit count, first/last seen) so coverage metrics are directly comparable across stacks.

Compatibility checks before any commitment

• PHP and Symfony version constraints vs. current runtime.
• Whether it requires dev-only dependencies (profiler, doctrine/dbal) that are unavailable in production.
• Whether the storage layer needs a migration and whether that schema collides with existing tables.

Sequencing

1. Route inventory and canonical naming convention (this is the hardest part; do it first).
2. Instrument in staging; validate that known-hot routes are detected.
3. Roll to production behind sampling, one to two release cycles of data.
4. Analyze and classify: unused, rare-use (cron/queue/webhook), and ambiguous.
5. Deprecate candidates with Deprecation/Sunset headers and a minimum observation window.
6. Remove only after a full business cycle (see false-positive risk below).

Operational Impact

Maintenance. Zero upstream. Budget an owner and roughly a sprint of engineering to fork or reimplement, plus ongoing ownership of the storage schema and retention job. This is not a "install and forget" line item.

Support. No vendor, no SLA, no security advisories. Any CVE in its transitive dependencies becomes our problem to detect and patch. For a package with zero dependents, assume it has never been exercised outside its author's environment.

Scaling. Per-request instrumentation is a write amplification problem. At meaningful traffic this produces millions of rows for a dataset whose useful resolution is "was this route hit in the last 90 days." Mitigate with in-process aggregation, sampling (10–20% is sufficient for coverage questions), a queue-buffered writer, and a hard retention window. Index on route identifier and date. The middleware must be excluded from health checks and asset routes to avoid skewing results.

Failure modes — the material risk is false "unused" classifications.

• Rare-path routes (quarterly billing jobs, annual exports, webhook receivers, admin tooling) look unused under any short observation window. Deleting them is an outage.
• Console/queue-invoked routes are invisible to HTTP middleware and will always appear unused.
• Parameterized routes can be collapsed or over-split depending on how the identifier is derived, producing phantom unused entries.
• Multi-tenant variance — a route used by one tenant and not others appears globally dead.
• Sampling error at low hit counts; a route hit three times may be missed entirely.
• Silent collection failure — if the writer errors, the dataset trends toward "everything is unused," which is the most dangerous possible failure direction. Add a heartbeat/canary route check.
• Environment leakage — staging traffic must never be mixed into production coverage data.

Ramp-up. Conceptually low (half a day for an engineer to understand); operationally medium (two to three weeks to make a fork trustworthy enough to justify deletions). The gating work is route naming discipline and the deprecation policy, not the code.

Recommendation. Do not adopt as a dependency. Extract the concept, implement or adopt the Laravel-native equivalent, and gate all removals behind an explicit observation window longer than your slowest business cycle with an owner sign-off step.