Filament Adjacency List Laravel Package

Product Decisions This Supports

• Build vs. buy for admin tree editing. Any feature that needs a nested hierarchy — navigation menus, product categories, ticket/subject taxonomies, org units, help-center sections, permission groups — needs a tree editor: add child, reorder siblings, indent/outdent, delete subtree. This package supplies that as a drop-in Filament form field, so the decision shifts from "do we staff a custom drag-and-drop UI sprint?" to "do we accept this dependency and its constraints?" That is typically a 1–3 week saving per surface, and the second surface is nearly free.
• Data model selection. It works against a plain self-referential parent_id + sort column, which keeps the schema simple and portable. If the roadmap later needs ancestor/descendant queries at scale, the documented path to Staudenmeir's laravel-adjacency-list (with customPath) means we don't have to re-platform the UI when we change the storage strategy. That lowers the cost of deferring the "adjacency list vs. nested set vs. closure table" decision.
• Feature scoping through configuration. Depth caps (maxDepth), per-action enablement (addable/editable/deletable/reorderable/moveable/indentable), orderColumn, label/children key mapping, and modal(false) for inline creation let us ship a constrained first version (e.g., two-level categories, no reordering) and loosen it later without new code. Good lever for phased rollouts and for tiering capabilities by plan.
• Permission and policy alignment. Release notes show drags are ignored on disabled fields and when policies disallow them, so tree UX can follow existing authorization rules rather than inventing a parallel model. That reduces the security review surface for admin tooling.
• Roadmap sequencing. Because it's admin-panel only and rendered through Filament, it's low blast-radius: we can prototype a hierarchical feature in an internal panel, validate the IA with ops or content teams, and only then commit to customer-facing navigation.
• Consistency across products. One shared tree interaction pattern across CMS, commerce, and support modules reduces design and QA duplication and gives us a single component to localize (the package already ships multiple locales).

When to Consider This Package

Adopt when most of these hold:

• The application is already on Filament (README and releases track Filament 4.x/5.x, Laravel 12/13) and the team is comfortable with the custom-theme step required to register the package's views.
• The need is an internal/admin tree editor, not a public-facing sitemap or menu builder.
• The hierarchy is modeled as, or can be modeled as, a self-referential relationship with an optional sort column.
• Tree sizes are moderate (tens to low hundreds of nodes per tree); performance work for large trees exists, but we should load-test our own data before assuming it holds.
• The team can pin a version, read the changelog before upgrades, and own the CSS/theme integration.
• A one-to-two-week delay to hand-roll an equivalent field is more expensive than accepting single-maintainer risk.

Look elsewhere or build in-house when:

• We are not on Filament, or the tree UI must live in a public frontend — the value is entirely in the Filament form/widget integration.
• We need tree editing with heavy concurrency, audit trails, or workflow (draft/publish per node); that logic belongs in our domain layer, not a form component.
• We require vendor SLAs, security review artifacts, or contractual support — this is a 100-star, MIT, community package with no dependents recorded and effectively one primary maintainer.
• Our depth or node counts are extreme and reordering must be atomic across large subtrees; validate with a spike first.
• The organization can't tolerate a dependency whose upgrade cadence is tied to Filament majors — a Filament upgrade could block our own release train.

How to Pitch It (Stakeholders)

For executives: This is a small, MIT-licensed UI component that gives our admin panel a production-quality drag-and-drop hierarchy editor — menus, categories, org structures — without a custom build. It's admin-facing only, so customer risk is minimal, and it removes roughly one to three weeks of design and engineering per screen that needs nested data. Cost is zero in license fees; the real cost is a dependency we must maintain.

For engineering: It's a Filament form field and widget (AdjacencyList) that binds to a self-referential relationship, with configurable label/children keys, depth limits, per-action toggles, custom actions, and an optional bridge to Staudenmeir's adjacency-list package for recursive queries. It supports Laravel 12/13 and Filament 4/5, and recent releases include meaningful correctness fixes around ordering, depth enforcement, policy-aware drag handling, and relationship persistence. Integration requires a custom theme and a one-line @source addition.

The honest risk statement: It's a young, single-maintainer package with a small public footprint. Mitigations: pin the version and review changelogs before upgrades; keep our usage to the documented surface (field, widget, relationship, order column) so a fork or replacement is a contained effort; spike against realistic data volumes before committing; and treat Filament major upgrades as the trigger to re-evaluate. Recommendation: adopt for internal admin tree editing where the alternative is a custom build, and avoid it where hierarchy editing is core, customer-facing, or workload-critical.