Menu Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy for navigation management. The core question is who owns navigation: developers (in code/config) or editors (in the back office). The database provider answers "editor-owned," which is typically correct once marketing or content ops owns the site and tickets start piling up for nav changes.
• Extension architecture: event-based contribution vs. central config. MenuEvents lets feature modules add their own nav items rather than editing one shared menu array. For a PM this is the difference between shipping a new feature as a self-contained unit and shipping it with a cross-team merge conflict in the admin navigation. It is the more strategically interesting half of the package.
• Roadmap proof point for "content changes without deploys." Nav editing is a frequent, low-risk, high-visibility example of removing engineering from the content loop. Ship it early as the credibility win that justifies broader CMS investment.
• Use cases to scope against: admin sidebar composition across modules; front-end header/footer/utility menus edited by marketing (paired with website-bundle); per-site or per-locale menu trees; permission-gated items so users only see destinations they can reach.
• Downstream features it unblocks: role-scoped navigation, multi-location menus, ordering and nesting, and onboarding new modules without touching core navigation code.
• Platform consolidation. If the strategic decision is "standardize on the Integrated suite vs. stitch together standalone Laravel/Symfony packages," this is one of the line items that makes the suite coherent rather than a loose set of repos.

When to Consider This Package

Adopt if:

• You are already committed to the Integrated suite, especially website-bundle. This is the natural navigation layer and integrates without glue code.
• Non-engineers need to change navigation, and you want it in the same backend as the rest of the content rather than a second CMS.
• Your admin navigation is assembled from multiple modules and you want an event seam instead of a central file everyone edits.
• It is an internal back office where you control the whole stack and can absorb upstream churn.

Look elsewhere if:

• You are not on Integrated. Zero stars, zero dependents, no external docs, no third-party tutorials, no hiring pool. This is also a Symfony bundle, not a Laravel package — if your stack is Laravel, budget for a framework adapter (service provider, dispatcher bridging, Doctrine vs. Eloquent) or stop here. Outside the suite, adoption is an unhedged bet on an unproven dependency.
• You need a mature nav API with a test suite, semantic versioning, and a security history. The opportunity score reflects an undiscovered package, not a validated one.
• Navigation is static or developer-owned. A database layer adds queries and cache invalidation for no benefit; routes and config are simpler.
• You need rich capabilities — mega-menus, drag-and-drop tree editing, scheduling, personalization, A/B testing. Verify the provider actually models depth, ordering, and locale before assuming.
• Bus factor is a blocker.

Evaluation checklist before committing: read the provider for N+1 queries and caching behavior; confirm the tree model supports depth, ordering, and locale; check whether items can be permission-scoped; review release cadence and test coverage; confirm it is not Symfony-only in practice. Then wrap retrieval behind a thin internal interface so a future swap is a replacement, not a rewrite.

How to Pitch It (Stakeholders)

To executives: It lets marketing and operations change site navigation without a ticket or a deploy, and it keeps admin menus modular so new features plug in rather than requiring edits to a shared file. Cost is near zero — MIT, small footprint, roughly a few days of engineering to prove out. The caveat to state plainly: it is early-stage, tied to one ecosystem, and effectively unmaintained upstream, so frame it as an accelerator for the Integrated suite, not a strategic platform bet. Success metrics: median time-to-change for a nav edit, and deploys avoided per quarter.

To engineering: It gives you a clean seam — MenuEvents for contribution, a database provider for persistence — so navigation stops being a hardcoded array and stops generating merge conflicts. Be honest about the risks: it is a Symfony bundle with Symfony/Doctrine assumptions, so a Laravel shop owns the adapter; nobody outside this ecosystem uses it, so there is no external battle-testing and no community bug reports. Mitigate by vendoring or forking a pinned copy, wrapping retrieval in a small internal interface, writing our own tests around ordering, permission, and locale behavior, and caching DB reads at the edge of the request with invalidation on menu-edit events. If we are not on Integrated, price the alternative first: spatie/laravel-menu or a simple menus / menu_items pair is comparable effort with far more support behind it.