- Does migrify/symfony-route-usage work with Laravel?
- No. It is a Symfony Bundle that expects Symfony's Kernel, RouteCollection, dependency-injection container extension registration, and event dispatcher, none of which have a direct analogue in Laravel's middleware pipeline. There is no adapter path, so it cannot be installed into a Laravel application and simply work. Treat the repository as a design reference rather than a dependency.
- What is the Laravel-compatible alternative to symfony-route-usage?
- The closest match is spatie/laravel-route-usage, which implements the same idea natively on Laravel's middleware pipeline. If you need a bespoke schema, you can also build it yourself in under a sprint: enumerate Route::getRoutes(), attach a terminal middleware that records the matched route name, and reconcile the observed set against the registered set on a schedule. Either option avoids pulling Symfony framework code into a Laravel app.
- How does symfony-route-usage detect used and unused routes?
- The inferred mechanism is that it instruments request handling and persists each route hit to storage, then diffs the observed routes against the registered route table to report the ones never seen. The detection model is sound and portable in principle; only the implementation is bound to Symfony. The repository's own documentation is thin, so verify the exact mechanism in source before relying on it.
- Is migrify/symfony-route-usage still maintained?
- No. The repository sits under a deprecated-packages directory with zero stars, zero dependents, and a composite score of zero, which means no CVE pipeline, no Symfony 6 or 7 compatibility work, and no bug triage. Its PHP version bounds are effectively unknown. It is source-available reference code, not a maintained dependency.
- Can I require migrify/symfony-route-usage with Composer in a Laravel project?
- Composer may resolve it, but that does not make it usable. The package needs symfony/http-kernel and bundle registration that Laravel's service provider system will never pick up, so no routes will be recorded and no report will be produced. Installing it only adds dead weight and a transitive Symfony dependency surface to your lockfile.
- Which Laravel and PHP versions are supported by route-usage tools?
- For this package there is no documented support matrix, and no compatibility work has been done for current Symfony or PHP releases, so assume it is already incompatible with a modern runtime. Laravel applications should use a Laravel-native package instead, which publishes its own Laravel and PHP constraints in composer.json. Always check those constraints against your runtime before committing.
- How do I implement unused route detection in Laravel myself?
- Register a terminal middleware that records the resolved route name or URI pattern into a bucketed store, then reconcile the observed set against Route::getRoutes() on a schedule. Aggregate per route per day rather than writing per request, and add sampling if write volume is a concern. Converge on a shared reporting schema of route identifier, service, hit count, and first/last seen so metrics stay comparable across services.
- Does route usage detection produce false positives?
- Yes, and they are the main operational risk. Routes invoked from cron, queue workers, console commands, webhooks, or rarely used admin endpoints can look unused inside a short observation window. Classify results as unused, rare-use, or ambiguous, announce deprecation with Sunset headers, and only remove a route after a full business cycle of data.
- What is the performance cost of recording route hits on every request?
- A naive implementation writes to storage on each request, which adds latency and grows tables fast. Aggregate per route per day, batch writes, or sample traffic so the instrumentation stays off the critical path. Also confirm the storage schema does not collide with existing tables and that a retention job prunes old rows.
- Should we fork migrify/symfony-route-usage?
- Only if you still run Symfony services and want a short-lived analysis tool in a non-production environment. The repository has zero upstream activity, no vendor, no SLA, and no security advisories, so a fork means you own the code, the schema, and the retention job indefinitely, and you should budget roughly a sprint of engineering plus ongoing ownership. For a Laravel estate the better answer is to port the concept to middleware or adopt a Laravel-native package and keep this repo purely as a design reference.