Menu Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy for the navigation layer. This package is a candidate answer to "do we hand-roll menu trees, admin editing, and role-based item visibility, or adopt something?" Its scope is menus as a persisted, hierarchical domain object rather than hard-coded nav arrays — the kind of work that is individually small but recurs in every product surface (admin, storefront, account area).
• Whether navigation becomes a content-owned concern. If non-developers need to reorder, rename, retarget, or hide menu items without a deploy, that is a roadmap item, not a nice-to-have. This package implies a data model plus editing surface, which is the difference between "shipping nav changes in a sprint" and "shipping them in an afternoon."
• Multi-tenant and permission-aware navigation. Menus that vary by role, plan tier, or tenant are a common late-stage retrofit that forces a rewrite of whatever naive structure shipped first. Choosing an abstraction now avoids that migration.
• Localization and caching decisions. Menu labels/URLs are high-read, low-write data — a natural cache target. Adopting a menu abstraction forces the team to state its caching and i18n story explicitly instead of discovering it during a performance incident.
• Framework direction. The *Bundle naming and SheGroup's ecosystem indicate Symfony, not Laravel. If the roadmap commits to Laravel, this package is not a dependency decision at all — it is at best a reference implementation for the data model and admin UX.

When to Consider This Package

Consider it when:

• You are on Symfony and want a thin, MIT-licensed menu bundle rather than a from-scratch implementation.
• Your requirement is genuinely modest: a persisted tree, ordering, labels, targets, and visibility rules — not a page builder or a CMS.
• You are willing to vendor or fork it and own it, with a named maintainer inside the team.
• It ships something you'd otherwise spend 1–2 sprints on (entity model, tree persistence, admin form types).
• You want a starting schema and API shape to crib from, even if you don't install it.

Look elsewhere when:

• You are on Laravel — evaluate spatie/laravel-menu, knp-menu (framework-agnostic), or a first-party abstraction instead. The nomenclature mismatch is a real integration cost, not a cosmetic one.
• You need active maintenance. Zero stars, zero dependents, and a last release of September 2023 mean no ecosystem, no downstream bug reports, and no obvious security disclosure path. That is a bus-factor-of-one risk profile.
• Navigation is on a critical path (revenue surfaces, checkout, authenticated shells) where a stalled dependency becomes an incident.
• You need tree operations at scale (deep hierarchies, drag-and-drop across thousands of nodes), versioned/published menus, or a headless navigation API.

How to Pitch It (Stakeholders)

To executives: This is a free, permissively licensed (MIT) component that could save us roughly one to two sprints of navigation work. The cost is not licensing — it is ownership. Adoption numbers are effectively zero, so there is no community to lean on and no vendor to escalate to. The honest framing is: we would be buying a head start, not buying support. If navigation is not a differentiator, this is a reasonable shortcut; if it is customer-facing and revenue-adjacent, we should budget internal ownership from day one.

To engineering: Treat this as a fork-and-own dependency, not a library we consume passively. Recommended path: timeboxed spike (2–3 days) to evaluate the entity model and admin surface; if it fits, abstract it behind an internal MenuProvider interface so the underlying implementation is swappable; pin the version and vendor the source. Note the framework question up front — if we are Laravel-first, stop here and use this as a design reference only. Either way, the data model (hierarchy, ordering, visibility rules, i18n labels) is the reusable asset, and it is worth extracting even if we never install the package.