Filament Menu Builder Laravel Package

Product Decisions This Supports

• Build vs. buy for navigation management. filament-menu-builder supplies the admin-side menu editor (tree structure backed by kalnoy/nestedset, link targets via the MenuItemTarget enum, Blade rendering) that would otherwise be a multi-sprint build. Choosing it converts a 4–8 week internal feature into a dependency decision.
• Roadmap sequencing for framework upgrades. v5.1.0 widens the nestedset constraint to ^6.0|^7.0, unblocking Laravel 13 installs. If Laravel 13 is on your platform roadmap, this package moves from "blocked" to "cleared" — and it is the kind of transitive conflict that quietly gates the whole upgrade.
• Which surfaces we can hand to non-engineers. A menu builder is the cheapest way to let marketing or client stakeholders restructure site navigation without a deploy. That directly supports any decision to reduce engineering involvement in routine content ops.
• Multi-panel / multi-site packaging. Because menus are a Filament resource, the same package can back several panels or tenant sites. This informs whether we standardize one CMS module across products rather than re-solving navigation per app.
• Scoping "CMS-lite" offerings. If the product direction is "editable site chrome without a full CMS," this package plus a pages resource is a viable scope definition — useful when deciding how much CMS to commit to.
• No decisions unlocked by the release itself. v5.1.0 is a compatibility and CI release: Laravel 13 support, matrix expansion to 11/12/13, toolchain constraint widening, PHPStan baseline regeneration, Pint rule adjustment. No new user-facing features, no deprecations, no breaking changes, no migration required for existing Laravel 11/12 installs (Composer continues resolving nestedset v6 there). Treat this as "the dependency stays viable," not "the product gained something."

When to Consider This Package

Good fit when:

• The application already runs a Filament panel (v3/v4/v5 line) and you want navigation editing inside the admin you already pay for, not a second UI.
• Menus are genuinely hierarchical and ordered — nested set storage plus drag/reorder is the core value; flat link lists do not need this.
• Navigation is edited by humans occasionally (marketing, client admins), so a resource-backed editor beats config files or hardcoded Blade.
• You are on Laravel 11 or 12 today and want a path to 13 without swapping the menu layer later. Existing installs are unaffected by v5.1.0; Composer keeps selecting nestedset v6.
• You are comfortable owning the rendering contract on your side (Blade partials, link resolution, caching) rather than expecting the package to own presentation.

Look elsewhere or build in-house when:

• There is no Filament panel, or the frontend is headless/API-driven and admin UX is a separate application — you would be adopting a Filament plugin for a non-Filament problem.
• You need menu capabilities beyond "structure and targets": per-item permissions, editorial workflow/publishing/scheduling, A/B or experiment-driven navigation, versioning and rollback, or translation-heavy menus with locale-scoped trees. Expect to build these on top, and price that in.
• Your platform standard is Laravel 13 with PHP 8.2. Laravel 13 test entries require PHP >= 8.3, so this is a hard floor on that track.
• You require vendor SLAs, security backchannel commitments, or a maintained LTS. This is a small-vendor package (Biostate) — the right posture is pinned constraint, changelog monitoring, and a credible fallback (own the tree model, swap the admin UI) rather than treating it as infrastructure.
• Menus are static and change with releases. A config file wins on simplicity.

Adoption checklist: confirm Filament v5 compatibility in your panel, verify the nestedset major Composer resolves (v6 on Laravel 11/12, v7 on 13), decide who owns the render layer, and check whether you depend on BladeCaptureDirectiveServiceProvider — v5.1.0 dropped manual registration in the package's own tests because Filament v5 no longer requires it, so any app-level registration is worth reviewing.

How to Pitch It (Stakeholders)

For executives (one paragraph): Navigation editing is a small feature with outsized operational cost — every nav change becomes an engineering ticket. This package gives us a self-serve menu editor inside the admin tooling we already run, so marketing and client teams can restructure site navigation without a release. The new v5.1.0 release is a maintenance release: it keeps us current with Laravel 13, so the dependency does not become the thing that blocks our next framework upgrade. No migration work, no user-visible change, no added cost. The trade-off is a small-vendor dependency, which we mitigate by pinning the version and keeping the render layer in our code so a swap stays cheap.

For engineering (summary):

• v5.1.0 is compatibility + CI only. Widened kalnoy/nestedset to ^6.0|^7.0; nestedset v7 requires illuminate/* >=13.0, so Laravel 13 installs now resolve (fixes the install conflict in #31).
• Laravel 11 and 12 installs are untouched — Composer continues to select nestedset v6. No migration, no code changes.
• CI now tests Laravel 11/12/13 instead of 11 only; PHP 8.2 excluded from Laravel 13 jobs (requires PHP >= 8.3). Dev constraints widened across Pest 2/3/4, larastan 2/3, testbench 9/10/11, PHPStan rules 1/2.
• PHPStan and styling now run on PRs and on composer.json / phpstan-baseline.neon changes — a real signal-quality improvement, and a reason to trust that Laravel 13 support is exercised rather than declared.
• Minor churn to note if you mirror their setup: manual BladeCaptureDirectiveServiceProvider registration removed from tests (Filament v5 no longer depends on it); Pint's lowercase_static_reference disabled because it mangled the MenuItemTarget::Self enum case; baseline regenerated for larastan 3 / PHPStan 2.
• Recommendation: bump to v5.1.0. It is low-risk, and being on it means a future Laravel 13 upgrade is a Composer resolution rather than an investigation. Pin the constraint, and keep menu rendering in our own Blade partials so the admin package remains replaceable.