Dashboard Menu Bundle Laravel Package

Product Decisions This Supports

• Navigation/menu architecture for admin dashboards: the bundle offers a ready model for hierarchical menus (parent + position) with permission gating and Twig rendering plus a JSON endpoint. That directly maps to "who sees which menu item, in what order, labeled how" — a decision most admin-facing products defer until it becomes a refactor.
• Build vs. buy for the menu subsystem: the realistic alternative isn't a competitor package, it's 2–5 days of engineering to model a menu tree, wire permission checks into rendering, and plumb translations. This bundle compresses that to configuration plus a Twig/JSON call, at the cost of owning an unmaintained dependency.
• Configuration-driven vs. database-driven menus: this package is config-first. That is a real product decision — config-driven means menus ship with deployments and are versioned in git (good for product-owned IA), but product/ops users can't reorder menus without a release. If a roadmap item is "let admins rearrange the sidebar," this package is the wrong foundation.
• Headless / multi-client navigation: the JSON API means the same menu definition can feed a Twig-rendered dashboard and a JS front-end or mobile shell. That supports decisions about whether navigation is server-rendered or client-rendered without duplicating the menu source of truth.
• Localization scope for chrome content: JSON-based i18n for menu labels makes "we ship in N languages" cheap for navigation specifically, and sets a precedent (file-based translations) that may or may not match the rest of the i18n strategy.
• Roadmap signal — dependency minimalism: the explicit "no Gedmo/Stof, no ORM extensions" stance is a positioning choice. If the org has been burned by transitive ORM extension conflicts, this supports a "keep the dependency graph boring" direction.
• Not supported by this package: per-user menu state (collapsed sections, favorites, pinning), usage analytics on navigation, dynamic menus built from runtime data (e.g., "recent projects" injected into the tree), or drag-and-drop menu administration. Those remain custom work either way.

When to Consider This Package

Consider it when:

• The stack is Symfony 7 or 8 on PHP 8.2+. Note the mismatch: this is a Symfony bundle, not a Laravel package — if the platform decision is Laravel, this is out of scope entirely and the comparison is against Laravel navigation packages or in-house config, not this.
• The menu structure is known at deploy time and owned by engineering/product, not by end users.
• You need tree ordering + permission visibility + i18n labels + Twig rendering + a JSON equivalent as a single coherent unit. That combination is genuinely fiddly to assemble correctly, especially permission filtering on nested nodes.
• You want to avoid Gedmo/Stof or any doctrine-extensions footprint in a codebase where those have caused upgrade friction.
• The blast radius of abandonment is acceptable: menus are read-path, presentation-layer, and swappable behind a small internal interface.

Look elsewhere (or build in-house) when:

• Adoption and support matter. 0 stars, 0 dependents, and a single-maintainer release cadence means no community triage, no third-party battle-testing, and no realistic expectation of a security or compatibility fix on your timeline. For a revenue-critical surface, that is a hard sell.
• You need runtime-editable menus. There is no admin CRUD story here; config-driven means redeploy to change navigation.
• You need nested-set or very large menu performance tuning, or menus assembled from database entities with lifecycle hooks.
• You depend on active-state/current-item resolution, breadcrumbs derived from the tree, or menu caching invalidation — verify these exist before assuming; they are commonly absent in small bundles of this shape.
• Your org has a minimum-maturity or supply-chain policy (SBOM review, maintained-dependency thresholds, security advisory response SLAs). This package will likely fail that gate regardless of code quality.
• You are on Symfony 6 — the stated target is 7/8, so a Symfony 6 LTS codebase may be unsupported despite the bundle's own internal conventions targeting 6/7/8.

Mitigation if adopted: vendor/pin the version, wrap it behind a thin internal menu-provider interface so the Twig/JSON surface is a single seam, and budget a few days to be able to fork it. Treat it as code you are borrowing, not a dependency you are consuming.

How to Pitch It (Stakeholders)

To executives (one paragraph): We can ship configurable, permission-aware, translated dashboard menus in days instead of weeks by adopting a small MIT-licensed open-source Symfony component rather than building it. The trade-off is maturity: it is a single-maintainer project with effectively no user base, so we should not treat it as a long-term strategic dependency. Recommendation is to adopt only if the menu surface is internal/admin-facing, pin the version, and isolate it behind our own interface so we can replace it in a sprint if needed — not to adopt it for customer-facing navigation or anything on a paid path.

To engineering (summary): Symfony 7/8, PHP 8.2+, MIT, no ORM-extension coupling. Provides a parent/position menu tree, permission filtering, JSON-file i18n for labels, Twig rendering, and a JSON API. Zero dependents and zero stars means zero external validation — assume you own the code. Constraints to confirm before committing: active-trail/breadcrumb behavior, cache invalidation, how permissions integrate with our voter/role model, and whether the Symfony 6 path we run in one service is actually supported. We would consume it behind an internal MenuProvider abstraction, pin to an exact version, and keep a fork ready.

Decision framing to put in front of the group:

• Buy (adopt) if: menu structure is deploy-time, audience is internal, and 2–5 engineering days are better spent elsewhere.
• Build if: menus must be editable at runtime, or navigation is customer-facing and needs analytics, personalization, or active-state nuance.
• Defer if: the platform decision is still open between Laravel and Symfony — this package is Symfony-only and is not a factor in a Laravel evaluation.