Routing Bundle Laravel Package

Product Decisions This Supports

• Framework reality check before anything else: despite the Laravel/PHP framing, modera/routing-bundle is a Symfony bundle, not a Laravel package. It hooks into Symfony's bundle/DI lifecycle and routing resource loaders; Laravel has no bundle abstraction and solves the same problem natively via loadRoutesFrom() in service providers. If the asking team is on Laravel, the decision is "not applicable" — close the ticket and move on.
• Plugin / modular architecture scoping: the underlying problem is legitimate — legacy Symfony required every bundle's routing to be manually imported into the host app's root app/config/routing.yml. For an installable-module platform, an internal bundle ecosystem, or a multi-tenant product with per-tenant modules, that host-app edit is a real per-install adoption tax. This package is evidence the pain exists and worth designing away.
• Build vs. buy — and the answer is build: the capability is roughly 20–50 lines (a compiler pass or PrependExtensionInterface that prepends a routing resource). The correct decision is "write it in-house" or "use the framework-native pattern," never "add this dependency."
• Roadmap input on integration friction: use it as a reference design when estimating how much onboarding cost your plugin system imposes on integrators. Every manual host-app edit you eliminate is measurable in install time and support load.
• Prior art for an internal design spike: the shape (bundles self-register routing resources; the host imports one fanned-out resource) is the right shape. That architecture is worth copying into our own small, tested implementation.
• What it should not drive: it is not a candidate for dependency review, security review, or vendor evaluation. Zero stars, zero dependents, archived ([READ-ONLY]), last release June 2016 — roughly nine Symfony majors ago, Symfony 2.x/3.x and PHP 5.x era. Treat it as prior art, not a component.

When to Consider This Package

Consider reading it (not depending on it) when:

• You maintain a legacy Symfony 2.x/3.x application that needs bundle self-registration and you are already comfortable vendoring or forking abandoned code.
• You are designing a plugin system and want a worked example of the compiler-pass-plus-routing-resource approach before writing your own — the pattern transfers; the code does not.
• Your team already has an internal fork and needs the pattern documented for onboarding.

Look elsewhere — decisively — when:

• You're on Laravel. Laravel already solves this: service providers call Route::middleware(...)->group(...) or loadRoutesFrom(__DIR__.'/routes/web.php'), and package routes are auto-discovered via RouteServiceProvider. There is no gap to fill and this package cannot be installed.
• You're on Symfony 4+. AbstractBundle::configureRoutes(RoutingConfigurator) (5.3+) and PrependExtensionInterface cover this natively, and Flex recipes can inject routing imports on bundle install. A modern Symfony app should use those, not a 2016 bundle.
• You need maintenance or security guarantees. No releases in ~9 years, no dependents, archived single-vendor split repo, no advisory feed, no maintainer on call. Vendor risk is maximal and total cost of ownership is entirely ours.
• You need it to run on a supported PHP/Symfony LTS. Compatibility is unverified and almost certainly broken; Composer resolution will likely fail outright against PHP 8.x + Symfony 5/6/7 without --ignore-platform-reqs hacks that push risk into runtime. Validating it would cost more than reimplementing it.
• Route registration volume is growing. As more packages register routes dynamically, name collisions, path shadowing, and nondeterministic ordering become likelier — and an unmaintained package offers no guardrails to catch them.

How to Pitch It (Stakeholders)

To executives: We evaluated a package that solves a narrow Symfony configuration annoyance — letting installed modules register their own routes instead of requiring a manual edit to the host application's config file. The need is real for our plugin strategy, but the artifact is a dead 2016 Symfony bundle with no users, no dependents, and no maintenance. It is not installable in a Laravel service, and it is superseded on modern Symfony. Recommendation: do not adopt as a dependency. The capability is roughly one to two engineering days to build in-house, or free from current framework conventions. Adopting it would import long-term maintenance, upgrade, and security-review liability for perhaps fifty lines of logic — and it would block unrelated dependency upgrades.

To engineering: The pattern is correct — a compiler pass (or PrependExtensionInterface) that collects and prepends routing resources so the host app's routing config stays untouched. That is the right shape for a plugin architecture. But this implementation predates Symfony 4 and is archived; assume it does not run on our stack. Three paths, in order of preference: (1) Laravel: call loadRoutesFrom() from the package service provider, wrap in Route::middleware()/prefix() groups driven by publishable config, and add route-name prefixes to avoid collisions — this delivers the stated capability with zero third-party surface. (2) Symfony ≥5.3: implement AbstractBundle with configureRoutes(RoutingConfigurator); on older 2.x/3.x legacy, PrependExtensionInterface prepending a framework.router.resource entry is the exact behavior this bundle provides, in ~30 maintained lines we control. (3) Only if a hard constraint forces it: vendor the archived source under src/ThirdParty/, pin an exact commit, and isolate it behind a thin adapter so it can be swapped. Either way, treat this package as a design reference, not a dependency. And if someone proposes it for a Laravel service, stop them — it's a Symfony bundle and is simply not installable there.

Decision to record: reject as a dependency; capture the pattern; build the ~30–50 line native equivalent with contract tests covering route names, prefixes, middleware, ordering, and route-cache behavior on deploy. Score it reject / replace natively, not onboard.