Filament Navigation Laravel Package

Product Decisions This Supports

• Build vs. buy for the "editable site navigation" feature. This package collapses what is typically a 1–2 sprint internal build (a menus/menu_items schema, a nested drag-and-drop editor, reordering persistence, link-target and label fields) into roughly a half-day integration. The decision it unblocks is: do we spend engineering on the menu builder, or on the rendered menu and its performance? This package forces the second answer, which is the right one.
• Marketing/CMS self-service roadmap. Structured, nestable menus are table stakes for any content-managed site — header nav, footer columns, utility bars, mega-menu groupings. Shipping this package is what lets us put "marketing can change the header without a deploy" on the roadmap and actually deliver it in the current cycle rather than deferring it behind more visible features.
• Scoping the content-management surface we own vs. rent. Because the package handles authoring but not rendering, it draws a clean line: we rent the admin UI, we own the Blade partial, active-state logic, and caching. That is a product decision with a real cost attached — someone must own the frontend partial — and it should be tracked as a deliverable, not assumed free.
• Multi-panel and multi-tenant scoping. The plugin registers per Filament panel, which means we decide which admin surfaces get menu editing. Defaulting to one admin panel and gating access with a policy is a cheap product control that prevents non-admin roles from editing site chrome.
• Deferral of a full page/URL-management system. Navigation editing often arrives as the leading edge of "we need a CMS." Adopting this package is a deliberate decision to solve links, not pages — it buys time and keeps the CMS decision separate and better informed.
• Localization and multi-menu support as future scope. Menus are stored as structured trees with handles, which means the follow-on asks (per-locale navs, header vs. footer vs. mobile variants) are additive configuration, not a rewrite. That materially raises confidence in the v1 roadmap.
• Upgrade-cadence planning for the Filament dependency. This is the decision this package forces most sharply: v2 dropped Filament v3 support rather than spanning both. Our Filament major-version upgrade cadence now has a hard, coordinated dependency attached to it, and that belongs on the platform roadmap, not in a ticket.

When to Consider This Package

Adopt when:

• We are already running Filament v4+ for the admin surface of the same application. This is close to non-negotiable — introducing Filament solely to obtain a menu builder is more total weight than a simple hand-rolled CRUD resource.
• The requirement is genuinely structured, nestable menu authoring — 2–3 levels, mixed internal routes and external URLs, reordering that non-technical editors perform unaided.
• We are content to own the rendering layer. A recursive Blade partial, active-state matching, and a cache with invalidation on save is small but real work, and it must be resourced.
• The team wants zero lock-in: MIT license, full source in vendor/, a plain JSON column, no compiled binary or opaque hosted service. If the maintainer walks away, forking or vendoring is realistic for a package this size.
• A single engineer can validate it in an afternoon — three commands and one provider line — so the cost of a failed spike is negligible.

Look elsewhere when:

• We are on Filament v3 or earlier. The v1 line exists but is in maintenance rather than feature development; adopting it means adopting a branch that will not follow our upgrades.
• We are not on Filament at all, or the admin surface is Livewire/Nova/custom. The integration cost then includes standing up Filament, which inverts the build-vs-buy math.
• We need page-aware menus — per-page visibility rules, permission-based item rendering, scheduled publishing, A/B variants. This package stores links; it does not model content relationships. That is a CMS, and pretending otherwise creates rework.
• Menu structure is developer-owned and changes rarely. A config file and a static template is cheaper, testable in code review, and version-controlled — no database table, no admin policy, no cache.
• Our risk posture cannot tolerate very thin adoption (10 stars, 0 dependents, single-digit contributor pool, a release history dominated by Dependabot and Tailwind bumps). The code surface is small enough that this is not disqualifying, but it means we will be among the first to hit edge cases — nested reordering bugs, permission gaps, Filament minor-version breakage — and we should have an engineer who can read and patch the source.
• A foundation-backed or first-party solution is a hard procurement requirement, which this is not: continuity rests on one Dutch agency rather than an individual — better than abandonment, not the same as institutional backing.

Gating questions to answer before commitment: which panels get the plugin (recommend exactly one); whether the handle column is uniquely constrained at the database level, since seeding and the template contract both depend on handle lookup returning exactly one record; whether a policy is needed to stop non-admin roles editing site chrome; and whether the package's tested Filament minor-version range and CI matrix actually cover the version we run, or only the latest.

How to Pitch It (Stakeholders)

To executives — one paragraph. Marketers currently cannot change the header, footer, or utility navigation without filing an engineering ticket and waiting for a release train. This package gives them a drag-and-drop menu builder inside the admin panel we already run, for roughly half a day of integration work against a feature we would otherwise build over one to two sprints — or keep deferring. It is MIT-licensed, small, and fully in our control: no vendor contract, no hosted service, and a realistic exit if the maintainer ever stops. The visible cost is that we build and own the front-end template that renders the menu, which is modest and one-time; the recurring cost is that our Filament upgrade cadence now carries one coordinated dependency. Net: a low-cost, low-blast-radius capability that removes a standing bottleneck between marketing and shipping.

To engineering — the shape of the work. Three install commands and a single ->plugin(FilamentNavigation::make()) line in exactly one panel provider. One new table, published assets, and a package-owned JSON tree. No service-provider configuration of consequence, no queues, no scheduled work, no credentials, no external dependency. The blast radius is confined to a new table, published assets, and one Blade partial we write. Our real deliverables are the recursive render, active-state logic, a cache with invalidation on save, and a policy gating who can edit site chrome — plus confirming the handle column is uniquely constrained at the database level, since both seeding and the template contract rely on single-record lookup. Registering in one panel only; do not spread it across contexts where a menu builder makes no sense.

The honest risk statement to put in front of both audiences. Adoption signal is thin — 10 stars, 0 dependents — so we will be early on edge cases and should budget an engineer comfortable patching a vendored dependency. The v2 release dropped Filament v3 support rather than spanning both, so when Filament ships v5 we should expect a coordinated major bump here and a constraint change rather than a graceful deprecation; that is the single most reliable future-breakage vector and belongs in upgrade planning now. Mitigating all of it: MIT license, full source available, plain JSON storage, no compiled binary, no opaque service — forking or vendoring is a priced-in option, not a hope. Recommendation: adopt, conditioned on Filament v4 and on resourcing the rendering partial and policy explicitly rather than treating them as implied.