Nova Nested Tree Attach Many Laravel Package

Product Decisions This Supports

• Admin UX investment in hierarchical catalogs. This field answers one narrow but high-friction question: can an editor attach a product/record to multiple categories through a browsable tree instead of a flat multi-select or a spreadsheet? If taxonomy assignment is a recurring support ticket, a manual ops step, or an error-prone copy-paste workflow, this is roughly a half-day integration that removes it. That is a measurable operational win — framed as an incremental admin improvement, not a platform initiative.
• Build vs. buy for niche admin UI. The real comparison is not "package vs. nothing," it's "package vs. a sprint of custom Nova field work." At ~35 stars, zero dependents, MIT license, and a single maintainer, the honest framing is buy the source, own the code: fork at the pinned 1.8.0, add one smoke test, pull it via a VCS repository. Acquisition cost is low; ownership cost is permanent but small because the surface area is a thin field wrapper over Nova's standard pivot flow.
• Roadmap sequencing for taxonomy features. Because the field is a presentation layer over an ordinary BelongsToMany pivot, it does not constrain or prejudge your data model. Ship it, measure whether editors actually use tree navigation versus search, and revert with a one-line field removal if they don't. This is a low-regret experiment — appropriate to slot as an incremental admin improvement, not a quarterly initiative or a line item that blocks other roadmap work.
• Scope control on page-builder / flexible-content features. The 1.8.0 relation-less mode lets marketing add promo or layout blocks that carry a category selection without inventing a new Eloquent relation per block type — genuine reduction in schema churn and migration overhead. The tradeoff is that you own persistence and integrity (JSON blobs, no foreign keys, orphaned IDs over time, no cascade deletes). Treat it as beta: decide once whether the payload is a flat ID array or full node objects, write a validation rule, and add read-time filtering of deleted IDs before you let it near a customer-facing page.
• Risk management as a first-class decision input. Three risks belong in the decision record, not in a footnote: (1) Nova version lock-in — this is 2021-era Nova 3 / Vue 2, so a Nova 4/5 upgrade likely means patching the Vue component in your fork; budget the fork as the actual cost of adoption. (2) Silent data loss on detach — attach-many fields differ on full-sync vs. additive save semantics; verify with a seed fixture before production or ops will experience it as lost categorizations. (3) Tree scale ceiling — the whole tree loads on every form render with no lazy loading or server-side search; test at 500 and 5,000 nodes before committing to tree UX as the primary interaction.
• Security and compliance boundaries. The package bakes in no authorization, multi-tenancy, or audit trail. Those must be enforced where they already belong — resource authorizedToAttachAny policies, a tenant global scope on the tree query, and Nova activity logging. A field that surfaces nodes a user isn't permitted to attach is a real security bug, so test it explicitly rather than assuming the package handles it.

When to Consider This Package

Adopt when all of these hold:

• You are on Laravel Nova 3 (or have accepted the fork-and-patch cost for Nova 4/5) and the version matrix in composer.json passes a ten-minute constraint check. A failed constraint solve or a Vue 2 asset in a Vue 3 Nova is an immediate reject — don't spend a spike on it.
• Your schema is a genuine self-referential BelongsToMany (e.g. category_category pivot with multiple parents per node). If your model is a single parent_id, the attach-many semantics are the wrong shape and this is the wrong tool.
• Hierarchical browsing is a real editor need, not a nice-to-have. Run the zero-dependency comparison first: rebuild the same screen with core Nova's searchable BelongsToMany field. If search wins on usability, take the option with no external dependency — the tree is a nicety, the dependency is forever.
• Volume is modest: a few hundred to low thousands of nodes, one instance of the field per form. Above that, scope the underlying query to a subtree or fall back to search.
• You accept fork ownership as the operating model — pin exact versions, keep a smoke test (attach two nodes → assert pivot rows; detach one → assert full-sync result; relation-less JSON round-trip plus orphan pruning), and re-run it on every Nova upgrade.

Look elsewhere when:

• You need pivot enrichment (position, ordering, per-attachment metadata). This is a selector, not a pivot editor — do ordering and metadata through a Nova Action, observer, or purpose-built screen instead of fighting the component.
• You need lazy-loaded trees, server-side search, or large-catalog performance. A 2021-era Vue 2 tree has no answer here, and adding one means effectively rewriting the frontend.
• You are on Nova 4/5 and the fork patch estimates at more than a week — writing a tree-select against your own Nova version is a legitimate, and often cheaper, alternative.
• Downstream reporting or search must join on those categories. In relation-less mode, values live in a JSON column, so analytics silently miss block-embedded selections — that's the argument for relational mode or a different approach entirely.
• You need vendor support, SLAs, or a maintenance guarantee. With one maintainer and a bus factor of roughly one, treat this as "lightly maintained," not "supported." Keep exit cost at a single field declaration.

How to Pitch It (Stakeholders)

To executives (one paragraph): We can eliminate a recurring manual workflow in admin — assigning records into nested category trees — with roughly half a day of integration using a small, MIT-licensed open-source field we will fork and own. It sits on top of our existing standard database relationships, so it commits us to nothing architecturally and can be removed with a one-line change if editors don't adopt it. The costs are small and bounded: we maintain a pinned fork, carry one regression test, and re-verify on each Nova upgrade. The main constraint is that our Nova version determines whether it works out of the box or needs a short patch, and at very large category volumes we'd revert to a searchable picker. Recommendation: approve as a low-regret admin improvement with a defined exit path, not as a platform bet.

To engineering (summary): Thin Nova field wrapping standard BelongsToMany attach/detach through a nested tree UI. Pin ^1.8, fork on day one, pull via VCS repository, do not float on dev-master. Acceptance test is the loop, not a feature list: seed 10 → 500 → a few thousand nodes; open form, expand tree, attach two, save, reopen, detach one, save, and re-save unchanged to prove save semantics. Index parent_id and both pivot columns first — a missing index will look like a package bug. Keep authorization, tenancy scoping, and audit in policies/global scopes/activity logs, not in the field. Note that 1.8.0 adds a query-cache flush on save for models using laravel-eloquent-query-cache, so the upgrade is not behaviorally inert — review that diff. Customization surface is three places: chainable methods on the field (read src/NestedTreeAttachMany.php for the authoritative list), global scopes on the related resource, and model observers on both sides of the pivot. Beyond that, patch the fork — it's cheaper than lobbying upstream.

Decision ask: Approve a timeboxed spike (one engineer, ~1 day) to confirm the Nova version matrix and run the attach/detach acceptance loop against a realistic seed. Go/no-go criteria: field renders and persists correctly, unchanged re-save does not wipe pivot rows, and the tree stays responsive at our current category volume. If any of those fail, fall back to core Nova BelongsToMany with search and close the item.