Dashboard Menu Bundle Laravel Package

Technical Evaluation

Architecture fit. nowo-tech/dashboard-menu-bundle is a Symfony bundle, not a Laravel package. It ships the standard Symfony bundle surface: a DI extension for configuration, Twig templates and Twig functions for rendering, a JSON API controller layer, and a tree model backed by parent + position fields. There is no ServiceProvider, no config/*.php Laravel-style config, no Blade integration, and no Illuminate contracts. The "Laravel/PHP package" framing in the brief should be corrected before any planning: for a Laravel application the fit is effectively zero out of the box, and the only routes are (a) a fork/port, (b) a rewrite of an equivalent menu service, or (c) drop the dependency. For a Symfony 7/8 application the fit is good — it is a self-contained, framework-native concern with a small, explicit contract (config → menu tree → Twig render + JSON read model).

Integration feasibility. Mechanically straightforward on Symfony: composer require, register the bundle, publish/author a menu tree definition, wire the permission check, render via Twig or consume the JSON endpoint. The deliberate absence of Gedmo/Stof extensions is a genuine plus — it removes a transitive tree-behavior dependency and the associated upgrade friction, and keeps the persistence contract portable. The unknown is the permission model: the description says "permissions" but not through what abstraction (Symfony Security voter, role strings, a callable, an interface to implement). That single unknown is the largest determinant of integration effort and must be confirmed from source before committing.

Technical risk. High, and almost entirely supply-chain rather than technical:

Key questions to resolve before a decision.

1. How are permissions expressed and enforced — voter, role string, or a user-supplied callback? Does enforcement happen server-side on the JSON API, or only in Twig?
2. Is the menu tree defined in configuration, in the database, or both? Is there an admin UI, or is authoring developer-only?
3. Does the JSON API have authentication/authorization of its own, and does it filter by the current user's permissions or return the full tree?
4. What is the actual supported-version matrix versus the declared one — is there CI proving Symfony 7 and 8, or only one?
5. Who maintains it, and is there a stated support/deprecation policy?
6. Is the i18n JSON translation layer compatible with the host app's existing translator domain conventions, or does it introduce a parallel translation mechanism?

Integration Approach

Stack fit. Symfony 7/8 only. The package is not a candidate for a Laravel codebase. If the target application is Laravel, the honest TPM recommendation is to not integrate and instead budget a small internal menu service (a tree table with parent_id/position, a policy-gated resolver, and a JSON resource) — the package's feature set is genuinely small enough that a port costs more than a clean implementation.

Migration path. For a Symfony app currently hand-rolling dashboard menus: strangler-style. Introduce the bundle behind a feature flag for one non-critical dashboard, render its Twig output into an existing layout slot, and keep the legacy menu as the fallback. The JSON API lets you migrate the front-end navigation incrementally without a template rewrite. No data migration is implied, since entries are configuration-driven — confirm this, as a DB-backed tree would add a schema migration step.

Compatibility. Pin to the exact released tag and record the PHP/Symfony constraints in the app's composer.json. Because the bundle targets Symfony 7/8 and PHP 8.2+, it effectively sets a floor on your framework upgrade cadence — a bundle lag on Symfony 9 will block your own upgrade. Validate the declared matrix against the repo's CI before trusting it.

Sequencing.

1. Spike (1–2 days): read the DI extension, the permission hook, and the JSON controller. Answer the key questions above. This is a read of a small codebase, not a full audit.
2. Proof of concept: one dashboard, one role, both render paths (Twig + JSON) exercised, permission denial tested explicitly.
3. Decision gate: adopt / fork / build. Gate on permission enforcement being server-side and on a credible maintenance answer.
4. Rollout: single dashboard → all dashboards → remove legacy menu code.
5. Contingency: if forking, capture the fork intent in writing and keep the diff minimal so re-syncing upstream stays possible.

Operational Impact

Maintenance. The dominant cost is not code churn but dependency ownership. With a single publisher and zero dependents, your team is realistically the de facto maintainer for any bug you hit. Budget a named owner and a standing allowance for patch-level forks, even if you never use it. The "no Gedmo/Stof" design decision reduces long-term upgrade drag and is a point in the bundle's favor.

Support. Community-only, no SLA, no documented security disclosure channel. That is acceptable for a dashboard navigation concern and unacceptable for anything in the auth or payment path — which reinforces keeping this strictly scoped to presentation.

Scaling. The workload is cheap and cache-friendly: menu trees are small, read-mostly, and near-static per role. Render or serialize once per role and cache; invalidate on menu configuration change rather than per request. The JSON API is stateless and horizontally scalable as-is. Scaling is not where this package will hurt you.

Failure modes to instrument.

• Permission bypass — an item visible to a role that should not see it, or the JSON API returning the unfiltered tree. This is the highest-severity failure; assert it in tests, not just in manual QA.
• Tree corruption — a parent cycle or duplicate position producing a silently missing or reordered menu. Add a validation check on startup/CI.
• Translation gaps — a JSON translation key absent for a locale renders a raw key to users; needs a fallback assertion.
• Twig coupling — the bundle's template block structure becomes an implicit API; a minor upgrade could break custom overrides.
• Upstream abandonment — no release for a Symfony major cycle blocks your framework upgrade; track release cadence as a live risk, not a one-time check.

Ramp-up. Low for a Symfony developer: the public surface is configuration, a handful of Twig functions, one controller, and a documented tree schema — roughly 1–2 days to productive use, plus half a day specifically on the permission model. For a Laravel-only team the ramp-up is not a learning curve but a port project measured in weeks, which is the central reason to expect this package to be declined under the stated stack.