Menu Bundle Laravel Package

Technical Evaluation

What this package actually is. swp/menu-bundle is a read-only subtree split of SuperdeskWebPublisher/SWPMenuBundle, extracted from the Superdesk Web Publisher monorepo. That provenance matters more than the package name: it is a Symfony bundle, not a Laravel package. It ships a Bundle subclass, a DI Extension with a configuration tree, compiler passes, Doctrine ORM entities/repositories, and Symfony event subscribers — all of which assume a Symfony Kernel and a compiled dependency-injection container.

Architecture fit: poor. Laravel has no bundle concept. Laravel's container is not compiled the way Symfony's is, so compiler passes, tagged services, and prepend()/Extension::load() config merging have no native execution path. Wiring this in means either (a) embedding a Symfony micro-container inside Laravel to host the bundle, (b) forking and rewriting the bundle as a Laravel service provider, or (c) lifting the domain model and reimplementing. Options (a) and (b) are multi-week projects whose cost dwarfs the value of a menu tree.

Dependency-constraint blocker (the decisive issue). Last release is 2018-06-11, which places the constraint set in the Symfony 3.4/4.x and PHP 7.1–7.3 era. Current Laravel (10/11/12) pins symfony/* at ^6.2/^7.x and requires PHP 8.1+. Composer will not resolve both trees; installation fails on version conflicts before any code runs. Clearing that requires replace/--ignore-platform-reqs hacks or a fork that bumps every Symfony constraint — and once bumped, the 2018-era code (annotations, deprecated form/event APIs, nullable-typing assumptions) will not run unmodified on PHP 8. Verification step: read the split's composer.json and the parent repo's composer.json at the matching tag before any further work; confirm the symfony/framework-bundle, doctrine/orm, and php constraints.

Technical risk: high.

• Abandonment. No release in ~7 years, 0 stars, 0 dependents on this split. No security patching, no PHP 8 compatibility work, no maintainer response path through the split (issues/PRs route to the monorepo, which has its own roadmap priorities).
• Split-package trap. Because this is a read-only mirror, you cannot meaningfully PR it. Any fix must be a fork, and you inherit the burden of tracking or abandoning upstream.
• Hidden coupling. Bundles of this vintage typically pull in sibling swp/* packages (menu domain, common utilities, templates system). Expect a transitive fan-out into Superdesk-specific abstractions that are meaningless outside that CMS, plus Doctrine entity mappings and schema assumptions (tree/nested-set columns, ordering fields, publication state) that will not match a Laravel app's schema conventions.
• REST/API surface. If the bundle exposes controllers or serialization config, those are Symfony-routing and serializer artifacts — no reuse in Laravel without rewriting.

Key questions for the team.

1. Is the actual requirement "a hierarchical, orderable menu/navigation model" or "reuse Superdesk's menu semantics"? If the former, Laravel-native options (nested-set/adjacency-list packages, kalnoy/nestedset, or a small custom model) dominate on every axis.
2. Are we standardised on Laravel? If the host app is Symfony, this package becomes plausible — but check whether the monorepo's current SWPMenuBundle is materially newer than this 2018 split, in which case the split is simply stale and should not be consumed at all.
3. Is there a licensing/IP constraint from Superdesk Web Publisher (AGPL/GPL-family is common for publishing platforms) that affects linking it into a proprietary product? Confirm before any code is read into the codebase.
4. What is the acceptable cost ceiling? A fork-and-port is 3–6 engineer-weeks plus permanent maintenance; a from-scratch menu model is typically 3–5 engineer-days.

Recommendation: Do not install. Treat as a reference implementation — mine the domain model (menu → menu items, tree reordering, publication scoping) for requirements and edge cases, implement natively in Laravel.

Integration Approach

Stack fit. Laravel + this bundle is a cross-framework integration, not a dependency addition. There is no supported path where composer require swp/menu-bundle results in working code in a Laravel app.

Migration path (if reuse is mandated). Ranked by cost:

1. Fork + port to a Laravel provider — fork the split, update all Symfony constraints, replace the Bundle + Extension with a ServiceProvider + published config, convert Doctrine annotation mappings to attributes or Laravel migrations, reimplement compiler-pass logic as explicit bindings. Highest fidelity, highest cost, and you own the fork forever.
2. Symfony container shim — keep the bundle intact inside a bootstrapped Symfony container (symfony/dependency-injection standalone) invoked from a Laravel provider. Avoids rewriting the bundle but introduces two containers, two service lifecycles, and duplicated Doctrine management. Rejected unless the bundle is enormous.
3. Extract the domain model only — copy entity shapes, tree-move algorithms, and validation rules into Laravel Eloquent models and policies. No runtime coupling, no fork. Recommended.

Compatibility. Expect incompatibility at four layers: PHP (7.x → 8.x), Symfony components (4.x → 6/7.x), Doctrine (annotation driver removed in ORM 3), and Laravel's own conventions (routing, validation, serialization, config). Each is independently blocking.

Sequencing (if pursuing option 3, the realistic path).

1. Gate 0 — licence and provenance check. Read the monorepo licence and confirm the split's tag corresponds to a real upstream release.
2. Gate 1 — constraint audit. Record composer.json requirements; confirm the Symfony/PHP wall. Document the finding; this decision memo justifies the "no install" call.
3. Model extraction. Catalogue menu/menu-item fields, tree strategy (nested set vs adjacency list), ordering semantics, publication/locale scoping, and any soft-delete or versioning behaviour.
4. Native implementation. Laravel migrations + Eloquent models; a nested-set or path-column strategy depending on read/write ratio; API resources for the read path.
5. Behavioural parity tests written from the extracted spec, not from the PHP source.
6. No production dependency on swp/* at any point — assert this in CI (composer why swp/menu-bundle must be empty).

Operational Impact

Maintenance. Option 3 (reimplementation) leaves zero third-party surface: the menu model is ordinary Laravel code under normal review, dependency-bot, and static-analysis coverage. Options 1 and 2 create a permanent fork obligation — framework upgrades (Laravel major, PHP minor), security triage on abandoned transitives, and a bus-factor of one unless a second engineer is deliberately onboarded.

Support. There is no support channel. Zero dependents and zero stars mean no community, no Stack Overflow corpus, no issue history to search. Any defect is yours alone. Escalation to upstream is unrealistic for a read-only split of a CMS whose roadmap is driven by its own product.

Scaling. Largely a function of the tree strategy, not the package. A nested-set implementation reads cheaply and writes expensively (reordering touches a subtree of rows); an adjacency list reads recursively. For menu data — read-heavy, small row counts, admin-time writes — either is fine at typical scale. The real scaling caution is the shim option: a second DI container bootstrapped per request adds latency and makes profiling and queue-worker behaviour harder to reason about. Avoid it.

Failure modes to plan for.

• Silent constraint drift — a transitive swp/* package resolves to an unexpected tag and behaviour changes invisibly. Mitigate by pinning exact versions if any Superdesk code is ever vendored.
• Schema collision — bundle entity mappings assuming column names/types (lft, rgt, root, level, position) conflicting with existing tables. Mitigate by explicit migration ownership.
• Upgrade dead-end — the PHP 8 wall arriving mid-project after partial integration. This is why Gate 1 precedes any coding.
• Licence contamination — copyleft obligations discovered late. Gate 0 exists for this reason.

Ramp-up. For a Laravel team, reading this codebase costs 1–2 days (Symfony bundle idioms are unfamiliar but not exotic). Porting costs 3–6 weeks. Reimplementing natively costs under a week including tests. The asymmetry is the whole argument.

Verdict. Score 0 with 0 dependents and a 2018 release is an accurate signal here, not a measurement artefact. Use the package as a design reference; do not take a runtime dependency on it.