Weave Code
Weaver
Helps Laravel developers discover, compare, and choose open-source packages. See popularity, security, maintainers, and scores at a glance to make better decisions.
Feedback
Share your thoughts, report bugs, or suggest improvements.
Subject
Message
Routing Tools Bundle

Routing Tools Bundle Laravel Package

ruwork/routing-tools-bundle

A small Symfony bundle from Ruwork that adds practical routing tools and helpers to your application, streamlining common route configuration tasks without changing how you define routes. Lightweight and unobtrusive.

View on GitHub
Deep Wiki
Context7

[READ-ONLY] Subtree split of the Ruwork Routing Tools Bundle

Frequently asked questions about Routing Tools Bundle
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.
Weaver

How can I help you explore Laravel packages today?

Conversation history is not saved when not logged in.
Prompt
Add packages to context
No packages found.
middlewares/firewall
qubiqx/montapacking
nyoncode/laravel-package-console
pnscripts/filament-broadquill-lite
pnscripts/laravel-sentfold-lite
vleap/mx-sdk-laravel-internal
twidpay/utils
htetmyathlaing/scout-elasticsearch-driver
artisan-toolbox/front-awesome
ls/client-assistant
users-au/laravel-client
robertmarney/lara-hierarchial-collections
simonschaufi/rule-doc-generator
emissaoja/emissaoja
blackbricksoftware/gravityforms-civicrm-form-processor
al-rahabi/fancy-crud
jinas/dhivatar-component
mltstephane/laravel-quality
bernskiold/laravel-talentlms
bernskioldmedia/laravel-form-architect