Menubundle Laravel Package

Technical Evaluation

Framing correction that drives the whole decision. The package is listed as a Laravel/PHP package but is in fact a Symfony bundle — the Bundle suffix, Doctrine ORM persistence, KnpMenuBundle rendering, and Sonata Admin dependency all point to Symfony. From a TPM standpoint this immediately reframes the evaluation from "is this a good Laravel dependency?" (no) to "is the pattern worth borrowing?" (yes, with caveats). Any roadmap item that assumes we composer require this into a Laravel app is based on a false premise and should be corrected before it consumes sprint capacity.

Architecture fit. The capability on offer is narrow and well understood: store a named navigation tree, let a non-developer edit it, render it. That's a two-table CRUD domain plus a cache. It is not an area where we need a third-party framework abstraction — which means the value of the package is the contract shape (a MenuProvider resolving a menu by handle into a tree), not the implementation.

Integration feasibility. Low for our stack. A genuine Laravel integration would require replacing Doctrine with Eloquent, Sonata Admin with Filament or Nova, discarding the Symfony DI/bundle registration, and reimplementing the provider against Laravel's container and cache. At that point we are not integrating — we are using it as a reference design. Even inside Symfony, feasibility is gated on adopting Sonata Admin, a heavyweight framework brought in for one CRUD screen.

Technical risk. High, and concentrated in provenance rather than code quality:

• Zero adoption signal — no stars, no dependents, no production validation. No one catches regressions for us.
• No maintenance evidence — no visible release cadence, CI, or test suite; assume it is pinned to whatever Symfony/PHP versions object.bg runs internally.
• Unverified license — a hard gate before any code is copied, forked, or vendored.
• Implicit domain coupling — packages extracted from a single application commonly hardcode table names, roles, and entity assumptions that only appear at integration time.
• Transitive risk — we would be adopting an admin framework to solve a problem a few hundred lines of our own code solves.

Key questions to resolve before committing to a plan.

1. What is the license, and does it permit forking and internal redistribution?
2. Is MenuProvider an interface we can implement, or a concrete class with query logic baked in?
3. Which Sonata Admin / Symfony / PHP versions does it constrain, and are those still supported upstream?
4. Does the schema assume object.bg-specific entities, or is the menu table self-contained?
5. Where is the real value — the provider contract, the schema, or the admin UI? Only the first is worth borrowing.
6. What does its authorization model assume, and has the admin surface had any security review?

Verdict. Score 0 with no dependents is a reliable signal: this is not a dependency candidate. It is, at best, a reference for how someone else modeled menus, and a short one at that.

Integration Approach

Stack fit. None for Laravel. Conditional for Symfony, and only where Sonata Admin is already justified. The recommendation is conceptual port, not code integration — we take the interface idea and write our own, in our own idioms, with our own tests.

Migration path, in descending order of preference.

1. Borrow the contract, write the implementation (recommended). Define a MenuProvider interface — resolve by handle, return a tree, cache the result. Implement against Eloquent with menus and menu_items tables, expose editing through Filament or Nova, render via a Blade component. Realistically 2–4 engineer-days for a mid-level developer. Fully owned, fully tested, no license exposure.
2. Fork and modernize — only if we are a Symfony shop committed to Sonata. Strip the bundle scaffolding, retarget current PHP/Symfony constraints, isolate or replace the admin surface, add tests.
3. Vendor a pinned copy — only to preserve behavior during a migration off an existing object.bg-derived system. Treat as technical debt with an explicit removal date written into the ticket.

Compatibility checklist for options 2 and 3. PHP constraint vs. runtime; Symfony major; Doctrine ORM presence and version; Sonata Admin major and its own peer graph; PSR-4 namespace collisions with existing bundles; whether entities are MappedSuperclass (extendable) or concrete (fork required).

Sequencing.

1. License and provenance check — hard gate, stop here if unclear.
2. Read the source end to end; document the schema and the provider contract in a short spec.
3. Decide port vs. fork. Bias hard toward port.
4. If porting: freeze the interface, build persistence plus cache invalidation, build the admin surface, write fixtures for reproducible environments.
5. Ship behind a feature flag on one low-traffic menu location before site-wide rollout.
6. Delete the reference copy from the repo so it cannot quietly become a dependency.

Compatibility and roadmap note. Because there are no migrations, no fixtures, and no schema documentation, the first integration step is schema archaeology. Budget for that in estimation — it is consistently underestimated and it is where this class of package burns sprints.

Operational Impact

Maintenance. Whichever path we choose, we own the code from day one. There is no upstream to absorb framework upgrades, no release notes, no security feed. A ported few-hundred-line implementation costs roughly one engineer-day a year in routine framework upkeep; a vendored bundle tied to Sonata Admin costs materially more, because every Sonata upgrade becomes a migration project. That ownership asymmetry is the strongest operational argument against adoption.

Support. No vendor, no documentation, no community artifacts to search. Onboarding reduces to "read the source." Tolerable for a small provider; unacceptable for a transitive graph that includes an admin framework and its peer dependencies.

Scaling. The domain scales trivially — menu data is small, read-heavy, and cacheable at the provider boundary with invalidation on write. The real scaling concern is the admin surface: a low-QPS, high-blast-radius back office that must never sit on the public request path and whose authz model must be reviewed independently. Watch for N+1 queries on tree load; assemble the tree in one query or cache the assembled tree, not the rows.

Failure modes to design against.

• Navigation as single point of failure — an uncached provider call on every request means a DB blip takes down every page's chrome. Cache with a warm fallback.
• Stale cache after edit — the classic bug in this domain; tie invalidation to the write path, never a timer.
• Runaway recursion — self-referential parent_id schemas permit cycles; guard the tree builder.
• Admin exposure — misconfigured admin routes are a common and severe finding. Enforce auth at the route level and audit before launch.
• Route names stored in the database — renaming a controller silently breaks links. Keep route names as constants or enum cases so refactors fail at build time.
• Schema drift — a vendored copy's migrations will diverge from ours; never let two migration sources own the same tables.

Ramp-up. Code comprehension is cheap — roughly a day for a mid-level engineer to read and map it. The non-trivial cost is context: a Laravel team inheriting Symfony, Doctrine, and Sonata idioms pays a week or more in unfamiliarity tax for a problem we could solve natively in a few days. Combined with zero adoption signal, that asymmetry decides the question: port the idea, not the package.