- Is leaseweb/default-routing-bundle compatible with Laravel?
- No. It is a Symfony 2 bundle that hooks the Symfony HTTP kernel through event listeners, registers services in the Symfony DI container, and depends on symfony/symfony routing internals such as RouteCollection, RequestContext, and RouterInterface. Laravel's router is a separate implementation with its own middleware pipeline and route registrar, and there is no adapter seam between them. Treat the bundle as a reference design for the problem, not as a dependency you can install.
- Can I install leaseweb/default-routing-bundle with Composer in a Laravel application?
- Composer will refuse to resolve it. The bundle's constraints target symfony/symfony ~2.x and PHP ~5.5, while Laravel 10 and 11 pull symfony/* ^6 or ^7, so both dependency trees cannot coexist in one vendor directory. You can install it in an isolated throwaway project purely to read the source, but loading it inside a Laravel app is not feasible.
- Which Laravel versions does leaseweb/default-routing-bundle support?
- None. The last release was on 2016-06-11, long before any modern Laravel version existed, and the code is written against Symfony 2 conventions that Laravel never adopted. Symfony 2.8 itself reached end of life in November 2018, so even the original target stack is unsupported.
- What PHP version does leaseweb/default-routing-bundle require?
- The Composer constraints target PHP ~5.5. Laravel 10 and 11 require PHP 8.1 or newer, so the requirement is incompatible on both the language and the framework axis. Widening the constraints is not realistic because no maintainer is actively working on the package.
- Is leaseweb/default-routing-bundle still maintained?
- No. There has been no release in roughly nine years, the repository shows only about 8 stars and zero dependents, and there is no security response path. There is no evidence of anyone running it in production today, so it should not be treated as a supported dependency. The opportunity score attached to it signals an unmet need, not a package worth adopting.
- Is it safe to use an abandoned Symfony bundle in a Laravel project?
- You cannot install it in a supported Laravel application in the first place, so the practical exposure is limited to reading the code. The real risk is organizational: forking and shimming an unmaintained Symfony 2 bundle would leave you owning a fragile compatibility layer with no upstream fixes. If the underlying problem is real, budget for a clean-room implementation instead.
- What is the Laravel equivalent of default routing in Symfony?
- Most of the intent maps to Route::fallback() combined with route parameter defaults and implicit route model binding. A catch-all slug parameter plus a resolver that maps the slug to a default controller or entity covers the common case. Laravel's route groups, dynamic prefixes, and URL::defaults() handle the relative URL semantics that the bundle expressed in Symfony idioms.
- How do I implement convention-based controller and action routing in Laravel?
- Register a fallback route that accepts a catch-all parameter, then resolve the controller and action from that segment inside a route-model-binding resolver or a small middleware. Keep the resolution table explicit and cacheable rather than relying on filesystem scanning. This typically lands in 150 to 300 lines of Laravel-native code and is far cheaper than porting the bundle.
- How do I handle relative routing, tenant prefixes, or locale-prefixed URLs in Laravel?
- Use route groups with dynamic prefixes, URL::defaults(), and a request-scoped context object set by middleware. A middleware that records the current tenant or locale segment plus URL::defaults() reproduces nearly all of the relative routing behavior the bundle offered. Laravel's existing route() helper already handles the rest, so a port adds little value.
- Should I port leaseweb/default-routing-bundle to Laravel or rewrite the feature from scratch?
- Rewrite it. The reusable artifact is the problem framing, including default controller routing, relative URL semantics, and template fallback chains, not the Symfony-specific implementation. Read the bundle's listener and router code to extract the behavioral contract, write it up as acceptance criteria, then build it fresh with Laravel primitives such as Route::fallback(), implicit binding, URL::defaults(), and Blade view composers. Starting with the template fallback resolver is the lowest-risk first step.