Tomato Menus Laravel Package

Product Decisions This Supports

• Build vs. buy for menu management. This package is a candidate answer to a recurring product question: is admin-editable navigation a differentiator or commodity plumbing? It ships the standard 80% of a menu builder — nested items, ordering, multiple named locations, URL/route linking, JSON-or-database storage, and Blade/Filament rendering. If menus are supporting infrastructure, adoption converts a 3–5 day build into roughly a sprint-day of integration. If navigation is product surface (personalization, localization workflows, publishing states), the package does not reach, and the decision should default to build.
• Who owns navigation: engineering or the business. The dual-provider design is the most product-relevant feature here, not the menu model itself. JSON-backed menus ship with a release — code-reviewed, diffable, revertible — which means engineering owns the "primary nav was wrong on launch day" problem. Database-backed menus mean marketing or ops can edit at runtime without a deploy, the right call for sidebars, footer groups, and campaign links. A PM should force this choice per surface up front, because it silently assigns operational ownership and determines your incident response.
• Roadmap sequencing and scope containment. This belongs in the MVP or internal-tooling phase, not the platform phase. Adopting it early buys speed on a non-differentiating feature; adopting it late, onto a mature app with tenancy or permissions requirements, invites a schema migration you would rather not run under load. Treat it as a phase-appropriate accelerator with an expiry date, not a permanent layer.
• Risk-accepted accelerator, priced honestly. The adoption signals are weak: zero stars, zero dependents, a single-author ecosystem, and a last release in May 2024. The correct framing is "low-cost accelerator with a pre-planned exit." The PM decision is whether the team can absorb the overhead — a private mirror, a wrapper interface, pinned versions, and roughly a day a quarter for Laravel/Filament compatibility — because if that budget is not real, the sprint-day saved is illusory.
• Use cases to green-light: internal admin panels and back-office tools, MVP marketing sites, TomatoPHP- or Filament-aligned apps, role- or context-specific menu variants, and JSON-seeded default navigation. Use cases to block: multi-tenant CMS navigation, approval or versioning workflows, A/B-tested or personalized menus, headless content delivery, enterprise support requirements, or any surface where a stale menu is a revenue event.

When to Consider This Package

Consider it when:

• The product is a Laravel app already aligned with TomatoPHP conventions or Filament-style admin tooling, where integration cost is lowest and the admin surface comes largely for free.
• Menu management is a supporting capability, not a differentiator, and the team would otherwise spend three to five days on CRUD, ordering, and nesting.
• The product genuinely benefits from the JSON-versus-database split — reviewed nav shipped with releases, runtime-editable links for admins.
• Engineering is willing and able to wrap the package behind an internal interface (e.g. MenuRepository::tree($key)), own the Blade rendering, and mirror the repo internally on day one.
• A short, time-boxed spike can validate Laravel 12 / Filament v4 compatibility, the migration's tree-integrity behavior (cascade vs. orphan on parent delete, cycle guards, ordering under concurrent edits), cache invalidation on save, and rendering fit — before any commitment.
• The team can fork or patch if upstream stays quiet, and has budgeted maintenance for framework upgrades.

Look elsewhere when:

• The product needs guaranteed maintenance, security review, SLAs, or vendor support; this package offers none of those.
• Navigation requires permissions beyond a simple active flag, localization workflows, approvals, publishing states, or versioning.
• Multi-tenancy is required or plausible within a year — retrofitting a tenant scope into a global menu table is a migration better avoided than run under load.
• The app sits outside the TomatoPHP ecosystem, or dependency governance will not clear a single-maintainer package.
• Navigation is customer-facing at scale and a broken or stale menu is high-impact.
• The team cannot fork, cannot pin, or cannot fund the quarterly compatibility tax.

How to Pitch It (Stakeholders)

Executive summary. tomatophp/tomato-menus is an MIT-licensed Laravel package that manages navigation menus backed by either a JSON file or a database table, with Blade helpers for rendering and Filament integration for editing. It can remove roughly a sprint-week of commodity CRUD work on a capability most products treat as plumbing. The caution is adoption signal: zero stars, zero dependents, a single maintainer, and a last release in May 2024. The recommendation is to treat it as a tactical accelerator for low-stakes internal surfaces — not a strategic dependency for core navigation — with a wrapper interface and a pre-agreed exit path.

To engineering. Evaluate it as a thin menu CRUD and provider layer for Filament- or TomatoPHP-aligned apps. Before writing app code, read the service provider, the config (the provider switch is the key decision), and the migrations — the schema determines cycle guarding, cascade behavior on parent delete, and ordering stability under concurrent edits. Wrap it behind your own repository interface, render through Blade partials you own, cache the resolved tree and invalidate it on save, and mirror the repo privately with an upstream remote. Confirm Laravel and Filament major compatibility: a mid-2024 release sits in the L11 / Filament v3 window, and pairing adoption with a framework upgrade is how a small package becomes a three-day fire. Keep customizations to three extension points — service provider, config, model observers — so rebasing stays cheap, and set a stop-and-build threshold: if the spike surfaces more than two unresolved schema or caching concerns, a hand-rolled menus + menu_items pair is three to five days, fully owned, and eliminates the single-maintainer risk entirely.