- Can I install lephare/menu-bundle in Laravel with Composer?
- There is no viable Composer install path for a Laravel application. The package is a Symfony bundle, so it expects Bundle registration in config/bundles.php and a dependency-injection compiler pipeline that Laravel does not provide. Forcing it in through a VCS repository entry would still fail at boot because Laravel never instantiates Symfony Bundle classes.
- Is lephare/menu-bundle a Laravel package?
- No. Despite being catalogued as a Laravel or PHP package, it is a Symfony bundle. Its surface area includes a Bundle subclass, a DependencyInjection extension with a Configuration tree, compiler passes, and a Twig rendering extension, none of which are Laravel integration points.
- Does lephare/menu-bundle support Laravel 10 or Laravel 11?
- It does not support Laravel 10 or 11 because it is built for Symfony's bundle system, not Laravel's package discovery and service provider model. An archived Symfony bundle will also likely pin older symfony/* constraints that will not resolve cleanly on modern PHP 8.2+ runtimes. There is no Laravel version compatibility to rely on.
- Is lephare/menu-bundle maintained?
- No. The repository is archived and shows zero stars and zero dependents, which means there is no active maintainer, no downstream users surfacing bugs, and no obligation to respond to issues. It should be treated as reference material rather than an adoptable dependency.
- What parts of lephare/menu-bundle could be reused in a Laravel app?
- Only a narrow slice of domain logic is potentially reusable: the menu tree data model, item ordering, active-item route matching, permission or attribute visibility rules, and the renderer abstraction. That is a few hundred lines of logic wrapped in Symfony-specific glue you would delete. Porting it means writing characterization tests and taking ownership of the code.
- What should I use instead of lephare/menu-bundle for menus in Laravel?
- Use a maintained Laravel package such as spatie/laravel-menu, optionally with a custom data source for your menu definitions. For Symfony targets, knp-menu is the comparable maintained option. The cheapest deadline path is a maintained package, not a fork of an archived Symfony bundle.
- Can I fork lephare/menu-bundle and maintain it myself?
- You can fork it, but doing so converts a commoditized menu problem into a permanent, unfunded maintenance obligation. You would inherit an unverified domain model, need Symfony bundle literacy on a Laravel-focused team, and likely have to write tests first. Check the license before any code moves, because an archived repo without a clear LICENSE can block a fork or copy-paste port.
- Does lephare/menu-bundle have tests or a security policy?
- There is no evidence of a maintained test suite or a SECURITY.md in the provided evaluation. A fork without tests means inheriting an unverified menu model and writing characterization tests before trusting behavior. Without a security policy there is no CVE triage or disclosure path, which is a production concern.
- How do I build nested menus in Laravel without this package?
- Use a maintained Laravel menu package or build a small in-house model for menu items, nesting, ordering, route matching, and visibility rules. Render it with Blade components or a dedicated renderer abstraction, and drive definitions from config or the database depending on whether menus are static or runtime-editable. This keeps the Symfony bundle scaffolding out of your codebase.
- Is lephare/menu-bundle safe to use in production?
- No. The combination of archived status, zero dependents, no maintainer obligation, and no security path creates high technical risk that is organizational rather than complexity-driven. Adopting it would leave your team responsible for an unfunded fork with no bug traffic or PHP-version drift plan. For production Laravel work, choose a maintained alternative.