- Is ruwork/routing-tools-bundle a Laravel package?
- No. It is a Symfony bundle that depends on symfony/framework-bundle, the DependencyInjection compiler-pass model, service tags, and Symfony's route-loading conventions. Laravel has no bundle registration mechanism, so there is no supported way to load it into a Laravel application. The Composer entry is also a read-only subtree split of the Ruwork Routing Tools Bundle repository.
- Can I install ruwork/routing-tools-bundle in a Laravel app with Composer?
- Not in any supported way. The package requires symfony/framework-bundle and expects Symfony's container wiring, which Laravel's service providers do not replicate. You would either have to run Symfony alongside Laravel or extract the underlying helpers into standalone code. Forcing the install with --ignore-platform-reqs only hides untested compatibility problems.
- What routing features does this bundle actually add?
- It provides small practical routing helpers, such as route collection loaders, route name prefixing, and parameter conversion utilities. It does not change how you define routes; it streamlines a few common configuration tasks. The scope is deliberately narrow and lightweight.
- Does Laravel's built-in router already cover what this bundle does?
- Largely yes. Route::group, Route::prefix, Route::name, Route::bind, and implicit model binding cover the common cases this bundle targets. Any remaining gap is usually small enough to reimplement as route macros inside a service provider. That keeps the behavior native, tested, and on a supported upgrade path.
- Which PHP and Symfony versions does this bundle support?
- It is a 2018 bundle, so expect constraints around PHP ^7.0 or ^7.1 and Symfony ^3.3 or ^4.0. Modern PHP 8.x and current Symfony releases will typically fail Composer resolution. Forcing the install leaves you running code that was never tested against those versions.
- Is ruwork/routing-tools-bundle still maintained?
- No. The repository has been archived since 2018, with no upstream commits, no issue triage, and no security response channel. It has zero stars and zero dependents, meaning you would be the first production consumer. Because routing executes on every request, unmaintained code on that path is a correctness and security concern, not a cosmetic one.
- How do I get equivalent routing behavior in Laravel?
- Treat the bundle as a design reference rather than a dependency. Read the source, identify the specific behaviors you actually need, and reimplement them natively with a Laravel service provider and Illuminate\Routing route macros, or with plain Route::group, Route::prefix, and Route::bind usage. Realistically this is a short effort for a small helper set, and it should only be funded once the requirement is confirmed.
- If I fork or vendor the bundle, what should I watch for?
- Fork it under your own namespace, keep the MIT attribution, and document exactly where you diverge from upstream. You take ownership of security review for routing code that sits on the request resolution path. Expect friction from code that predates PHP 7.4 typed properties, PHP 8 union types, and Symfony 5 and 6 routing deprecations.
- Is it worth adopting if my application is actually Symfony, not Laravel?
- The integration mechanics exist there, but the abandonment problem does not go away. An archived 2018 bundle will not satisfy current Symfony dependency constraints without a fork. Budget that fork explicitly, assign an owner, and define a security review process before treating it as a dependency. If the stack is Laravel, the correct action is to close the evaluation.
- What are the alternatives to this package?
- For Laravel, the alternative is the native router itself, plus route macros or a small service provider if you need custom behavior. For Symfony, prefer a maintained bundle or write the small helper directly in your application. In both cases, copying a few ideas from this bundle's source is safer than depending on it.