Menu Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy vs. borrow — menu/navigation work. Navigation trees, active-state highlighting, and permission-filtered menus are on many roadmaps. This package is a useful reference point for that decision, not a candidate dependency. Its existence (and its archived, zero-dependent state) is evidence the problem is well-understood and commoditized, which argues for either a maintained off-the-shelf package or a small in-house implementation rather than reviving abandoned code.
• Roadmap risk scoring for dependency adoption. Adopting an archived package converts a dependency into a permanent internal fork. Any feature that would sit on top of it inherits an "adopt + own forever" cost that must be priced into the estimate — annual PHP major, framework major, and security-patch triage, none of which anyone upstream is doing.
• Framework-fit triage (fast "no"). The package is a Symfony bundle (Bundle suffix, symfony-bundle Composer type, DI/compiler-pass scaffolding), not a Laravel package. If the product is Laravel, this is a documented non-starter — a clean early rejection that saves a spike.
• Use cases it gestures at but does not serve: hierarchical navigation trees, route-aware active-item detection, attribute/permission-based visibility rules, pluggable rendering templates. If those appear in a roadmap item, treat it as a trigger to evaluate maintained alternatives (spatie/laravel-menu for Laravel, knp-menu for Symfony) or a Blade component plus an Eloquent tree — not to resurrect this repo.
• Prior-art input to internal design. As a data-model reference (tree definition, nesting, active detection, renderer abstraction) it can inform an in-house design without ever entering composer.json. That's a legitimate PM-visible use: cheap design input, zero supply-chain cost.
• Architecture/ownership decision. Choosing it forces a named owning team and a service-catalog entry. That's a staffing and accountability decision, not just a technical one, and belongs in the roadmap discussion.

When to Consider This Package

Consider it only as read-only reference material:

• You want prior art on how a small bundle modeled hierarchical menus before designing your own data model.
• You are supporting a legacy Symfony application that already depends on it and need to scope migration cost off it (this becomes a migration task, not an adoption task).
• You need a concrete example to argue for or against building a menu abstraction internally — a "here's what 300 lines of this looks like" artifact for a design review.
• You are doing competitive/ecosystem diligence on how the menu-rendering problem has been solved and why packages in this space get abandoned.

Look elsewhere when:

• The product is Laravel. Framework mismatch: no bundle registration, no Bundle base class, no DI compiler pipeline. The Symfony-specific scaffolding is most of the package's surface area and cannot load at all. Expect a class-not-found or container-resolution failure at boot — an outage, not a degraded menu.
• You need future compatibility. Archived means no security patches, no PHP-version drift plan, no Symfony/Laravel version support. On a supported PHP line (8.2+), stale transitive pins are a slow-motion breakage and a classic source of unresolvable composer.lock conflicts.
• The feature is user-facing and load-bearing. Primary navigation is on every page. Zero stars, zero dependents, archived, no SECURITY.md, no issue triage — the bus factor and abandonment risk are unacceptable for anything on a critical path.
• You need community support or documentation. None exists at this adoption level; internal support is the only support channel.
• Licensing is unverified. An archived repo with no LICENSE file is legally ambiguous and would block a fork or closed-source redistribution — a question to resolve before any engineering time is spent.

How to Pitch It (Stakeholders)

For executives: This is an archived Symfony package with no users, no dependents, and no maintainer. It is not a candidate for adoption — it's a signal, not a solution. The practical recommendation is: do not adopt it; budget navigation/menu work as either a small in-house build or a well-supported third-party choice (a few hundred lines of Eloquent plus a Blade component covers the common requirement). The important takeaway is process, not this specific package: we should evaluate dependencies on maintenance health and framework fit, not on convenience. Adopting unmaintained code is a false economy — the initial integration looks free, and we inherit every future fix, upgrade, and security patch forever.

For engineering: Treat lephare/menu-bundle strictly as reference material. It is a Symfony bundle, so there is no installable path in a Laravel 10/11 / PHP 8.2+ codebase — don't attempt composer require, and never place it in a shared dependency set (a Bundle-shaped class autoloaded in Laravel is a boot-time outage). If menu/tree structures hit the roadmap, run a 1–2 day spike: read the source, separate domain logic from Symfony scaffolding (DI extension, compiler passes, Twig extension), and confirm whether anything is genuinely non-obvious. If it's a thin wrapper with no interesting persistence model, close it out and implement natively against spatie/laravel-menu or a small Eloquent tree. If we do fork for a legacy Symfony migration, the gate is parity HTML-diff tests across representative trees (empty, single-level, deep, multi-locale, permission-filtered) — and a named owning team, a LICENSE, and a service-catalog entry before the first line is ported. Design against the known failure modes up front: cyclic parent_id references (depth cap or closure table with write-time cycle prevention), stale cache after editorial edits (cache key on a menu version stamp), and dangling references to unpublished or deleted pages in the primary nav.