Menu Bundle Laravel Package

Product Decisions This Supports

• Who owns navigation: decides whether menus are editor-managed content or developer-owned code. This bundle pushes nav into the admin UI (multiple named menus, ordered items), which is a real product commitment — editors can reshape IA without a release.
• Build vs. buy for a menu builder: it hands you a worked solution to a deceptively annoying problem — Menu/MenuItem entities, tree ordering, admin CRUD, localization hooks. Useful as a reference design even if you don't adopt it.
• Multi-menu scope: the package is explicitly built around "multiple menus" (header, footer, sidebar, mobile). That supports a roadmap where brands, locales, or sections each carry their own nav.
• Platform direction, not just a feature: adoption is a Symfony/Doctrine/Kunstmaan admin decision, not a nav-widget decision. It sits inside the KunstmaanBundlesCMS family, so it anchors the roadmap to that ecosystem.
• Dependency risk posture: 3 stars, 0 dependents, score 0.115, opportunity 30/100. You would be among the first non-Kunstmaan consumers. That's a signal to treat this as reference implementation rather than dependency.
• Fit: CMS-driven marketing/multi-site sites where editors reorder nav; not API-first products where nav lives in the frontend router.
• Flag for the record: this is a Symfony bundle, not Laravel. The "Laravel/PHP package" framing is inaccurate; there is no Laravel integration path.

When to Consider This Package

Adopt when:

• You're already on KunstmaanBundlesCMS, or a Symfony app with Doctrine ORM and the Kunstmaan/Sonata admin layer.
• You need editor-managed, multi-menu navigation with tree ordering and per-locale labels.
• You accept fork-and-own maintenance and can pin a version.
• MIT license satisfies legal — it does; permissive, no copyleft obligations.

Look elsewhere when:

• Non-Symfony stack. Hard coupling to Symfony forms, Doctrine, and Kunstmaan's admin/node infrastructure makes a Laravel port a rewrite. Use a Laravel-native nested-set/adjacency-list package plus a Filament or Nova resource.
• You need active maintenance or security responsiveness. Low stars, zero dependents, low opportunity score. Check commit recency before any commitment; assume dormant until proven otherwise.
• You need only one static nav. A config file or a 50-line model beats an admin bundle and its transitive dependencies.
• Headless / multi-channel delivery. You'd export the tree and rebuild the rendering anyway.
• You want a clean dependency graph with no CMS coupling.

How to Pitch It (Stakeholders)

Executives: A small, MIT-licensed Symfony bundle that lets editors manage several site menus from an admin screen instead of filing tickets for nav changes. It is not a strategic investment — adoption is negligible (3 stars, no dependent projects), so we would own the code from day one. Recommend evaluating only if we're already inside the Kunstmaan CMS ecosystem; otherwise integration and maintenance cost likely exceeds building a scoped menu model ourselves.

Engineering: Part of the Kunstmaan CMS bundle family — Doctrine entities for menus and items, tree storage, an admin controller and templates. It is Symfony, not Laravel; there's no adapter, and coupling to Kunstmaan's admin/node layer makes a port a rewrite. Treat it as a reference architecture — entity shape, tree strategy, admin UX — rather than a drop-in dependency. If we adopt, budget for forking, version pinning, and upstream tracking.

Decision framing: Low opportunity score (30) with zero dependents makes this a borrow the design, not the code candidate — unless we are already a Kunstmaan shop, in which case it's a low-effort win.