sed/route-exporter-bundle
A Symfony bundle that exports your application's named routes to a configurable file, making route names and paths available to frontend JavaScript and other consumers without hardcoding URLs. Includes a console command for regenerating the route map.
Architecture fit. The first thing to flag: this is not a Laravel package. sed/route-exporter-bundle is a Symfony2 bundle — it registers as a bundle in AppKernel, hooks into the Symfony DI container, and consumes the Symfony RouterInterface to enumerate and dump routes in YAML, XML, or PHP formats. Its architecture assumes Symfony's component model (bundles, compiler passes, services.yml), none of which map onto Laravel's service providers or its router. There is no Laravel-shaped surface to integrate with. What does transfer is the concept: a route-introspection-and-serialization layer that produces machine-readable route inventories for documentation, gateway config generation, or cross-service contract validation. That concept is worth evaluating; the artifact itself is not directly reusable.
Integration feasibility. Low as a drop-in. You would not install this into a Laravel app — Composer would resolve it, but nothing would execute, because no bundle kernel exists to load it and no Symfony router exists to inspect. Feasibility only rises if you're running a hybrid PHP estate with a legacy Symfony2 service, in which case it could be used within that service to emit a route manifest that the Laravel side consumes as data. That is a narrow, one-directional integration (file artifact, not code dependency).
Technical risk. High, concentrated in three areas. (1) Abandonment: Symfony2 reached end-of-life in 2016; this bundle targets an EOL framework and has 10 stars and zero dependents, meaning effectively no production usage to learn from and no security or compatibility maintenance. (2) Silent correctness drift: route exporters are inherently reflection-based — they enumerate what the router knows, so any route registered outside the framework's canonical mechanism (dynamic registration, attribute/annotation edge cases, conditional route loading) is either silently omitted or exported incorrectly. An inventory that is 95% right is more dangerous than no inventory, because downstream consumers trust it. (3) Format coupling: consumers will lock onto the YAML/XML schema the bundle emits, which has no versioning guarantee and no maintainer to evolve it.
Key questions before any commitment.
php artisan route:list --json been evaluated first? It is first-party, maintained, and covers the same ground.Stack fit. Treat this as a reference implementation, not a dependency. Read the bundle's route-to-format mapping logic, then reimplement the equivalent in the host framework's idioms: in Laravel, a small console command wrapping the framework router's getRoutes() and serializing to a stable JSON schema; in Symfony (any supported version), debug:router with a format flag already does much of this natively. The value extracted is the enumeration approach and the output shape, both of which are cheap to reproduce and cheap to own.
Migration path. If a Symfony2 service is the real consumer, the sequencing is: (a) pin the bundle at a known commit rather than tracking a branch, since there will be no upstream fixes; (b) run the export in CI and diff against a committed baseline so route changes surface as reviewable artifacts; (c) front the generated file with a thin adapter that normalizes it into whatever schema the Laravel side actually wants, so the Symfony-side format can be frozen. This isolates the abandoned component behind a boundary you control.
Compatibility. Non-negotiable constraints: PHP 5.x-era code will not run on PHP 8.x without patching — expect to fix deprecations, each()/curly-brace offsets, and any reliance on removed Symfony2 APIs if you attempt to run it at all. Composer's Symfony-flex era also means bundle auto-registration will not apply. Any attempt to modernize the bundle onto Symfony 4+ is a rewrite, at which point you should be writing the 200-line console command instead.
Sequencing. Validate the need before touching the code — one afternoon confirming whether route:list --json (Laravel) or debug:router (Symfony) satisfies the requirement, since either may close the ticket outright. Only if there is a genuine gap does building a small owned exporter make sense, and that build should be scoped to the consumer's schema, not to this bundle's feature set.
Maintenance. Effectively zero upstream maintenance; the 10-star / 0-dependent profile means no community to absorb CVEs, no issue triage, and no compatibility patches. Every hour of upkeep is yours. The offsetting argument is that the functional scope is tiny — route enumeration is not algorithmically hard — so a fork or clean-room reimplementation is a bounded, one-time cost rather than an open-ended liability.
Support. No vendor, no active maintainer, no SLA. Internal runbooks must document the export schema, the CI diff gate, and the escalation path, because there is no external party to escalate to. Bus factor is one until the reimplementation is reviewed by a second engineer.
Scaling. Low risk on the compute axis — route tables are small (hundreds of entries), and export is a batch/CI-time operation, not a request-path one. The scaling concern is organizational: as services multiply, each legacy Symfony2 service holding its own forked exporter becomes a fragmentation problem. A shared, owned route-manifest format across services is the durable answer; per-service copies of an abandoned bundle are not.
Failure modes. The dangerous ones are quiet. Silent omission of dynamically registered routes produces an inventory that looks complete and isn't — downstream gateway config or contract tests then pass against a phantom surface. Format drift across a fork produces exports that parse differently per service. And an unpatched PHP 5-era dependency becomes an incident the moment the host runtime is upgraded, which is a scheduled event, not a hypothetical. Each of these is mitigated by the CI diff gate plus a schema version on the emitted artifact.
Ramp-up. Near-trivial for anyone who has worked with Symfony2 bundles (~half a day to read the bundle and understand its output); moderate for a team with no Symfony2 exposure, since the framework itself is now archaeology. The larger ramp-up cost is the replacement: designing the manifest schema and wiring the CI diff gate is a few days of work, and that is the path I would recommend budgeting for rather than the integration itself.
Recommendation. Do not adopt as a dependency. Use route:list --json (Laravel) or debug:router (Symfony) if either satisfies the requirement; otherwise commission a small, owned exporter against a versioned schema. The bundle's 0.69 score reflects a coherent idea executed for a framework generation that has since ended — the idea is worth borrowing, the code is not worth carrying.
How can I help you explore Laravel packages today?