Nova Parental Field Laravel Package

Product Decisions This Supports

Primary decision: build vs. buy a ~150-line admin UI affordance — not a platform choice. This package is a Laravel Nova form field, not a domain module or service. It renders a <select> of candidate parent records for a self-referencing Eloquent model. That places it firmly in the "internal tooling / developer-experience" bucket: it accelerates content editors and ops staff working in the admin panel in Nova, and it touches nothing on the customer-facing request path. Frame the decision accordingly — this is a call a tech lead can make and reverse in a day, not an architecture review item.

Feature and roadmap enablement. It unblocks a recurring class of roadmap work where the product needs tree-shaped data with human editors behind it: category taxonomies, CMS page hierarchies, navigation menus, organizational units/departments, threaded content parents, product or document taxonomies. Without a parent selector, every one of those features carries a hidden "and now we hand-build an admin screen" line item. This package — or the 150 lines it represents — is the thing that removes that line item, which is its entire value proposition.

Scope and blast-radius decision. Because the surface is Nova-only, the risk calculus is materially different from a normal dependency review. A broken field degrades an internal workflow; it does not take down checkout. That justifies a lower evidentiary bar than we'd apply to a runtime package — but it also caps the upside, which is why the build-vs-buy delta has to be honestly small to justify any dependency at all.

The "do we need this at all?" decision — and this is the important one. Nova ships a native BelongsTo field, and Eloquent already supports self-referential relationships (parent() / children()). For a single-parent hierarchy, BelongsTo::make('Parent', 'parent', Resource::class)->nullable()->searchable() is close to zero custom code. The package's real differentiator is convenience (option labelling, excluding self/descendants, maybe formatting), not capability. The PM decision is therefore three-way: native field, copy the pattern in-house, or add the dependency — and the middle option is likely correct.

What it explicitly does not decide. It does not give us tree reordering, drag-and-drop, subtree moves, or depth limits; if the roadmap contains "editors reorder the category tree," this package is not the answer and Nova's ecosystem tree packages (or a bespoke tool) are a separate evaluation.

When to Consider This Package

Adopt it only when all of the following hold:

• The stack is pinned to Laravel Nova 3.x. Last release was July 2021 and Nova 4 landed in 2022, so Nova 4/5 compatibility should be assumed broken until proven otherwise in a throwaway skeleton on our exact versions.
• The use case is internal admin only — no customer-facing surface depends on it.
• The hierarchy is shallow and single-parent (categories, parent pages, org units), not a reorderable tree.
• The parent candidate set is small enough for a select — low hundreds of rows. A dropdown that loads thousands of options is a UX failure that the field will not solve for you.
• We accept exact version pinning plus a wrapper, and we've read the source (at 5 stars and a 0.0.0 tag, reading ~200 lines is faster than evaluating it).

Look elsewhere, or build it, when:

• We are on Nova 4 or 5, or plan to upgrade within the planning horizon — this is the most likely disqualifier.
• We need tree reordering, subtree moves, or depth constraints — different product, different package.
• The data is large or unbounded; a flat select is the wrong control.
• The hierarchy is many-to-many or multi-parent; this field models a single parent_id.
• The admin panel is customer-facing or revenue-bearing (white-labelled portals), where coupling to an unmaintained single-maintainer package is disproportionate.
• The team has any Nova experience — a custom field is roughly a day of work, and that day buys us permanent ownership of the behaviour, our own labelling rules, and no upgrade-matrix risk.

The honest baseline: at 5 stars, a 0.0.0 tag, no changelog, and a four-year-old last release, the correct disposition is read it, don't depend on it. Use it as a reference implementation and a time estimate.

How to Pitch It (Stakeholders)

For executives (30 seconds): This is a small, free, open-source add-on for our internal admin panel that lets staff pick a "parent" record when editing things like categories, pages, or departments — the kind of tree structure several roadmap items quietly depend on. It is not customer-facing, adds no ongoing licence cost, and cannot affect the live product. However, it was last updated in 2021 and is maintained by a single unknown author, so my recommendation is not to install it as a dependency. Instead, engineering reproduces the same behaviour in roughly one day of in-house work, which we then own outright. Net: we get the capability, we avoid an unmaintained dependency, and the cost is a day rather than a permanent upgrade risk.

For engineering (the actual ask):

• Recommendation: reimplement, don't adopt. Treat the package as a design reference and a build estimate, not a dependency.
• Rationale: Nova 3-only (last release July 2021, predating Nova 4), 0.0.x semver with no changelog, 5 stars, single maintainer, no visible CI or test signal. Adopting means we own fork risk and a Nova-upgrade blocker for the sake of ~150 lines of field code.
• First check before writing any code: does native BelongsTo against a self-referential relationship already satisfy the requirement? If yes, the ticket is configuration, not code. This should be the opening task.
• If we do build: scope it to a subclassed Nova field with options() limited to eligible parents (exclude self and descendants), explicit nullable() handling, and searchable behaviour for anything above ~50 options. Ship behind a config flag; add a Nova feature test so the field is covered before a future Nova major.
• Revisit trigger: if the upstream project reaches a stable, documented 1.0 with Nova 4+ support, re-evaluate — but by then we'll already own the code and the migration is trivial in the other direction.
• Cost of the recommendation: roughly one engineer-day, versus an ongoing 2–4 hours per upstream release plus a hard dependency on a maintainer who has not shipped in years.