Weave Code
Menu Builder Api Bundle Laravel Package
forci/menu-builder-api-bundle
Symfony bundle that exposes API endpoints for the Forci Menu Builder, enabling programmatic creation, retrieval, update, and deletion of menus and menu items. Add a ready-made menu management API layer to your application.
At a glance
Frequently asked questions about Menu Builder Api Bundle
- Can I install forci/menu-builder-api-bundle in a Laravel app with Composer?
- Not usefully. This is a Symfony bundle: it ships a Bundle subclass registered through config/bundles.php plus a DI extension, and Laravel has no bundle system to boot it. Composer may resolve the dependency graph, but nothing will register in a Laravel service container and no routes, config, or services will appear. Treat it as a reference implementation to harvest or consume over HTTP, not a one-line composer require.
- What does the bundle actually provide?
- It exposes the Forci MenuBuilder data model over HTTP: endpoints for menus and menu items, including nested hierarchies and their serialization to JSON. It handles routing, dependency injection wiring, and configuration so a frontend or another service can read and manage navigation trees programmatically. The valuable asset is the API contract and menu schema, not the Symfony plumbing around it.
- Is there a Laravel service provider, facade, or config stub?
- No. There is no evidence of a Laravel service provider, facade, publishable config file, or Eloquent model anywhere in the package. Everything is built around Symfony's kernel, routing, and container conventions. Any Laravel-side integration you build is custom code you own and must test yourself.
- How should a Laravel team integrate this if they want the functionality?
- There are three realistic paths. First, run the bundle natively inside a small Symfony service and have Laravel call its API over HTTP, which keeps the package intact but adds a second runtime, a network hop, and an auth seam. Second, extract or depend on a framework-agnostic Forci menu-builder core and rebuild routes, controllers, and persistence in Laravel. Third, and often cheapest for a single app, write a Laravel-native menu builder with an adjacency list or nested set table plus your own JSON endpoints.
- What is the license, and can I use it commercially?
- The repository license is reported as NOASSERTION, meaning it could not be automatically classified and may not be permissive. Do not assume MIT. Review the LICENSE file and composer.json license field with legal counsel before any engineering spend, since unclear terms are a hard stop for commercial use, modification, or redistribution.
- Which Symfony and PHP versions are supported?
- The README excerpt does not state explicit version constraints, so treat composer.json and any CI configuration as the source of truth. Expect a hard dependency on symfony/framework-bundle, and likely doctrine/orm and possibly api-platform/core or symfony/serializer. A pinned older Symfony minor becomes a real ceiling if you choose the standalone-service route.
- How is persistence handled — does it use Doctrine migrations?
- The bundle is built around Symfony conventions, so Doctrine entities and Doctrine migrations are the likely persistence layer, though the exact contract should be confirmed during a feasibility spike. Doctrine migrations do not map cleanly onto Laravel's migration runner, so assign schema ownership explicitly: either the Symfony service owns its tables and Laravel never migrates them, or you rebuild the schema natively. Check whether it can target an existing menu table or insists on its own.
- Does the API support nested hierarchies, ordering, visibility, and serialization?
- Yes, nested menu hierarchies and their serialization are core to what the bundle exposes. Ordering and visibility are part of the underlying MenuBuilder data model rather than something the API layer invents. During evaluation, capture the exact JSON shape for nested items so you can write contract tests against it, whether you consume the API or reimplement it.
- Does it handle authentication, multi-tenancy, and localization?
- There is no documented evidence of auth, multi-tenancy, or localization support in the API contract. Most likely it is single-tenant and English-only, leaving access control to whatever wraps the endpoints. If you containerize the bundle as a service, you own the auth seam between Laravel and that service, including token issuance and tenant scoping.
- Is it production-ready, and what are the alternatives?
- Signals are weak: zero stars, zero dependents, a single-vendor origin with no visible release cadence, and no implied test suite. That is not a disqualifier for harvesting a data model, but it is a poor bet as a runtime dependency. For most Laravel applications the strongest alternative is a small in-house menu builder with a nested set table and REST or JSON:API endpoints, which removes the framework mismatch, the license question, and the maintenance risk in one move.
Weaver
How can I help you explore Laravel packages today?