- Is shegroup/menu-bundle a Laravel package?
- No. It is built and named as a Symfony bundle: it relies on Symfony kernel bundle registration, DI Extension and Configuration compiler passes, Doctrine ORM mappings, and Twig rendering. Laravel's package contract is a ServiceProvider built on Illuminate components, Eloquent, and Blade, and there is no shim that lets a bundle load as a Laravel package. Treat it as a readable design reference for menus, not as an installable dependency.
- Can I install shegroup/menu-bundle in a Laravel app with Composer?
- Composer resolution is unlikely and runtime compatibility is effectively zero. The package declares Symfony-oriented requirements that will usually conflict with illuminate/support and illuminate/container constraints, and even if it installs, nothing registers config, routes, or views because Laravel only auto-discovers ServiceProviders. Do not add it to composer.json in a Laravel application.
- Does shegroup/menu-bundle support Laravel 10 or 11?
- No. There is no declared Laravel support, no ServiceProvider, no Blade directives, and no illuminate/* constraints, so Laravel 10 and 11 sit outside its supported matrix. Its last tagged release is from 2023-09-27 and its constraints target an older PHP and Symfony era. If your stack is Laravel, evaluate a native package instead.
- How do I install and configure shegroup/menu-bundle in Symfony?
- Require it with Composer, register the bundle in config/bundles.php, and add its configuration under config/packages. Verify the declared php and symfony/* constraints match your runtime first, because there has been no release since September 2023 and PHP 8.2 or 8.3 support is not guaranteed. Check the repository README for the exact bundle class and configuration keys.
- What Laravel alternatives should I use for hierarchical menus?
- For rendering, spatie/laravel-menu covers the item tree and active-state output with active maintenance and real dependents. For persistence, use kalnoy/nestedset or a closure table, and pair it with a Filament or Nova resource for editing. That combination typically covers around 80 percent of the feature surface in three to five days of work your team owns outright.
- How would I port shegroup/menu-bundle to Laravel?
- Treat it as a rewrite with the bundle as a spec, not an integration. You would port Doctrine entities to Eloquent models and migrations, the bundle config tree to config/menu.php plus a ServiceProvider, Twig extensions and renderers to Blade directives and a view composer, and the tree strategy to nestedset or a recursive query. Only do this if source review reveals non-obvious logic such as permission-aware visibility or multi-tenant scoping.
- How do I render menus in Blade instead of Twig?
- Twig extensions have no Laravel equivalent, so you would replace them with a Blade directive or component plus a view composer that passes a prepared menu tree into the view. Active-state detection also has to move from Symfony's request stack to Laravel's Request and Route facades, comparing route names. Realistically this is part of a port rather than a drop-in change.
- Which tree strategy and storage does shegroup/menu-bundle use?
- The overview confirms nested parent/child menus but does not state the tree model or storage engine. Doctrine entities are implied by the bundle structure, yet adjacency list, nested set, or closure table cannot be determined without reading the source. If you port it, choose the strategy explicitly and back it with kalnoy/nestedset or a recursive CTE.
- Is shegroup/menu-bundle maintained and safe for production?
- The signals are weak: zero stars, zero dependents, no visible CI or test evidence, and a last release on 2023-09-27. That means no community security review, no downstream battle testing, and no triage capacity if something breaks. The MIT license is the one clean dimension, so use it as a reference and skip it as a production dependency.
- How does automatic active item detection work, and how would I replicate it in Laravel?
- It marks the active item by comparing each item's route against the current request, and typically flags that item's parents as active too. In Laravel the equivalent is comparing item route names to Route::currentRouteName() and walking parent links up the tree. That logic is small enough to implement directly rather than porting the bundle.