Menu Bundle Laravel Package

Technical Evaluation

Architecture fit. The first finding a TPM must surface is a classification error in the dependency feed: shegroup/menu-bundle is named and structured as a Symfony bundle, not a Laravel package. Bundles rely on the Symfony kernel's bundle registration, Extension/Configuration compiler passes, Doctrine ORM mappings, and Twig rendering — none of which have a Laravel analog. Laravel's package contract is ServiceProvider + Illuminate components + Eloquent + Blade. The two are not interchangeable, and the shared surface is limited to the domain idea (a hierarchical menu with items, ordering, and visibility rules) plus a plausible database schema. Treat this as "a reference implementation to read," not "a dependency to install."

Integration feasibility. Low as-is. A real integration into a Laravel codebase would mean porting four layers: (1) Doctrine entities → Eloquent models and migrations, (2) bundle config tree → config/menu.php plus a service provider, (3) Twig extensions/renderers → Blade directives and a view composer, and (4) the tree strategy (adjacency list, nested set, or closure table — unknown without source review) → a package like kalnoy/nestedset or a hand-rolled recursive CTE. That is a rewrite with the original as a spec, not an integration.

Technical risk. High, and concentrated in provenance rather than code quality. Zero stars, zero dependents, and a last release of 2023-09-27 mean no downstream battle-testing, no community security review, and no triage capacity. Composer constraints are almost certainly pinned to an older PHP/Symfony matrix (likely Symfony 4/5 era), which will conflict with modern illuminate/* requirements if anyone attempts a naive composer require. There is also a plausible hidden coupling to Sonata Admin or a specific tree library, which would deepen the port. MIT licensing is the one clean dimension — permissive, no attribution friction.

Key questions for the maintainer/business before any decision.

• Is the target application actually Laravel, or is the stack Symfony and the feed simply mislabeled? This single answer changes the recommendation entirely.
• What are the declared php and symfony/* constraints, and does the code run on PHP 8.2/8.3?
• Which tree strategy and storage engine does it assume, and does it require Doctrine?
• Does it ship an admin UI (Sonata/EasyAdmin), and is that in scope for us?
• Is there CI, a test suite, or static analysis evidence of coverage?
• Who at SheGroup maintains this, and is there any commitment beyond the 2023 tag?
• What is opportunity: 32.05 measuring here — is there an internal roadmap item this package is being evaluated against?

Integration Approach

Stack fit. Binary. If we are a Symfony shop, this is a legitimate (if low-signal) candidate and warrants a half-day spike. If we are a Laravel shop — which the request implies — the correct posture is reject as a dependency, retain as a design reference. Do not vendor or fork it into a Laravel app without budgeting for an ownership transfer of the code.

Migration path. Three viable options, in descending order of preference:

1. Build thin, buy nothing. Implement menu + menu_items with kalnoy/nestedset (or a closure table) and a Filament/Nova admin resource. This is typically 3–5 days of work and produces code the team owns outright.
2. Adopt a native Laravel equivalent. spatie/laravel-menu for rendering plus a first-party tree implementation for persistence covers 80% of the feature surface with active maintenance and real dependents.
3. Port from MenuBundle as a spec. Only if source review reveals non-obvious business logic (permission-aware visibility, multi-tenant scoping, localization of labels) worth transcribing.

Compatibility. If option 3 is pursued, verify before writing code: PHP constraint, Symfony component versions, Doctrine DBAL/ORM major version, PSR-4 autoload layout, and whether any transitive dependency is itself abandoned. Any conflict with illuminate/support or illuminate/database is a hard stop on reuse and confirms the port-only route.

Sequencing.

1. One-day source audit (constraints, tree strategy, admin coupling, test presence) — gate for everything downstream.
2. Confirm the actual target framework with the requesting team.
3. If Laravel: schema extraction → Eloquent models/migrations → repository + tree service → admin CRUD → Blade rendering helper → cache invalidation hooks.
4. Feature-parity checklist against the bundle's public API before declaring done.
5. Defer localization and permission-awareness to a second increment unless already required.

Operational Impact

Maintenance. Effectively zero upstream velocity. A 2023 tag with no stars and no dependents implies a dormant or internal-only project; expect no fixes for PHP 8.4, no security patches, and no response to issues. Any adopted code becomes ours to maintain indefinitely — that is the real cost, and it should be stated explicitly in the business case rather than buried.

Support. No SLA, no vendor relationship, no commercial backing. GitHub issues are the only channel and may be unmonitored. Escalation path is "we fix it ourselves." This is acceptable for a fork we own; unacceptable if anyone assumes the package is a supported dependency.

Scaling. Menu trees are inherently small (tens to low hundreds of nodes), so raw query volume is not the concern. The real scaling risks are (a) recursive/nested-set reads on every page render if not eager-loaded, (b) N+1 queries when resolving per-item permissions or labels, and (c) cache invalidation complexity once menus are cached per-tenant or per-role. Budget for a cache layer and a deterministic invalidation trigger (model events → tagged cache flush) from day one.

Failure modes.

• Silent breakage on runtime upgrade — no upstream to patch PHP/Symfony incompatibilities.
• Abandoned transitive dependency — a Doctrine or tree library that stops receiving security fixes.
• Tree corruption under concurrent edits — nested-set writes are not concurrency-safe without locking; adjacency lists are safer but cost recursive reads.
• Stale cache serving wrong menus — especially across tenant or role boundaries; a cross-tenant menu leak is a security-adjacent incident, not a cosmetic bug.
• Scope creep into admin UI — if the bundle's admin layer is Sonata-based, replicating it in Filament/Nova is larger than the persistence port and often underestimated.

Ramp-up. Domain comprehension is fast — menus are well-understood. The cost is in the port and in the ownership transfer: expect roughly one to two sprints for a Laravel-native implementation with admin CRUD and caching, versus a half-day to assess and a near-zero marginal cost if the stack turns out to be Symfony. Recommend framing the decision as build vs. port rather than adopt vs. reject, because adoption is not actually on the table.

TPM recommendation. Do not add shegroup/menu-bundle as a dependency. Confirm the target framework, run a one-day source audit purely to harvest design intent and schema, then execute the Laravel-native build. The 32.05 opportunity score and zero-adoption signals are consistent with a package that has reference value but no dependency value.