Nova Parental Field Laravel Package

Technical Evaluation

Scope note: This is not a general-purpose Laravel package. It is a Laravel Nova field — a UI extension for a paid, closed-source, first-party admin panel. That single fact drives most of the risk below: the field's runtime contract is with Nova's internal field API and Vue component conventions, not with a stable public Laravel contract. Nova majors (3 → 4 → 5) have historically required field rewrites, and this field's last release was 2021-07-08, which places it squarely in the Nova 3 era.

Architecture fit

The package occupies a narrow, well-defined slot: it renders a select control on a Nova form for a model that points at itself via a parent foreign key (categories, pages, org units, menus). It is a presentation-layer convenience, not a domain module. Assess fit on four points:

• Is it the field, or the behaviour? The name references "Parental," implying a companion package (wamadev/parental) supplies the self-referential trait/relationship and this field is only the form control. A TPM must establish whether the valuable logic lives upstream in a package we are also implicitly adopting, or whether the field is self-contained. If the field hard-depends on the trait, our real dependency footprint is two packages, one of which we have not assessed.
• Does it duplicate a native capability? Nova ships a BelongsTo field that can be pointed at the same resource to express a self-referential relation. The build-vs-adopt delta is therefore small — likely searchability, depth indentation, or cycle filtering. If the package's only differentiator is a <select> populated from a table, our own ~100-line field matches it in an afternoon.
• Frontend surface we inherit. Nova fields are PHP + Vue. Adopting means owning build tooling assumptions (nova.mix, component registration, Vue 2 vs 3). This is a materially larger maintenance surface than a backend-only package, and it is the part most likely to break on a Nova upgrade.
• Escape hatch. A Nova field is replaceable without touching domain code — worst case we swap the field class in the resource's fields() method. That is a genuine mitigating factor: blast radius on removal is one line per resource.

Integration feasibility

Install is trivial (Composer + Nova field registration in a resource). The real work is compatibility proof, and the timeline makes that doubtful:

Technical risk

• Platform-upgrade coupling (High). The worst failure mode is not "the field breaks" — it is "the field blocks our Nova upgrade." A stale Nova field can pin the whole admin panel to an EOL Nova major, which in turn pins Laravel and PHP. This elevates a cosmetic admin widget into a platform-strategy dependency.
• Data integrity (High, and under-documented). Nothing in the description claims cycle prevention or self-selection blocking. A parent selector that permits record.parent_id = record.id, or A→B→A, corrupts tree data and can hang any recursive renderer downstream. Validate this explicitly in the spike.
• Authorization scoping (Medium-High). Does the option list respect Nova policies, lenses, and multi-tenant scoping — or does it pluck() the entire table? An unscoped list leaks record names across tenants/roles and is a reportable defect, not a UI nit.
• Scale behaviour (Medium). A <select> populated with every row is unusable and memory-hostile past a few thousand records. Confirm whether it uses Nova's searchable/async BelongsTo machinery or a flat option array.
• Abandonment (High). No release in ~4 years, minimal traction. Assume we own the fork.

Key questions (blocking — hours to answer, quarters of rework if skipped)

1. Which Nova major(s) does it declare support for, and does it render on our Nova version today (spike, don't read)?
2. Is wamadev/parental a hard dependency, and if so what does it own — trait, relationship, cycle guard?
3. Does the parent option list respect Nova authorization/tenant scoping?
4. Can a record select itself or a descendant as parent? Is there any server-side validation?
5. Does it scale to our largest hierarchical table, or is it a flat pluck()?
6. Exact PHP/Laravel/Nova constraint bounds, and are they open-ended?
7. Test suite, CI on the tagged commit, and maintainer identity?
8. What is the delta versus (a) native Nova BelongsTo in self-referential mode, (b) a first-party field we write in 1–2 days?

Integration Approach

Stack fit

Evaluate against our pinned Nova major and Laravel/PHP versions, not latest. Nova is the binding constraint, not Laravel — a field can be perfectly Laravel-compatible and still be dead on the Nova side. Install into a throwaway Nova install on our exact versions, register against a real hierarchical model, and exercise create/edit/update.

Migration path

Greenfield adoption — no incumbent, so this is an evaluation, not a migration. Sequence:

1. Spike (1–2 days). Branch on our Nova version. Prove: renders, saves parent_id, respects policies, blocks trivial cycles (or documents that it doesn't), behaves at realistic row counts.
2. Build-vs-adopt decision gate. If the spike reveals missing authorization scoping or cycle handling, those are fixes we must write anyway — at which point the build path is cheaper and the adoption case collapses.
3. Thin wrapper, if adopted. Prefer a first-party field class extending or delegating to the package, registered in resources under our name. This keeps removal to a one-line change per resource and survives a Nova upgrade that kills the upstream component.
4. Single resource first. Roll out on one low-risk hierarchy (e.g. internal tag categories), not the customer-facing navigation model.
5. Document the version pin. Exact Composer constraint + committed lock. No ^ on an unmaintained package.

Compatibility

Pin exactly and treat Nova-major upgrades as a joint ticket with this package's status. If the package cannot run on our target Nova version, stop — do not fork-to-upgrade unless the build path was already rejected, because forking a Vue field is a real cost with no strategic payoff. Add a Renovate/Dependabot rule that surfaces upstream releases but never auto-merges.

Sequencing

Spike → build-vs-adopt decision (explicit, written) → wrapper → single-resource canary → broad rollout. Do not schedule the broad rollout before the Nova upgrade roadmap is known; those two decisions must be made together.

Operational Impact

Maintenance

Budget on the assumption we own this code. Realistic ongoing cost is low in absolute terms (a handful of hours per Nova major, a couple of hours per year for review) but non-zero forever, and it lands on whoever owns the admin panel at upgrade time. If the field also pulls in wamadev/parental, that package's maintenance profile — trait, migrations, relationship behaviour — is the bigger, less visible line item.

Support

No maintainer SLA, no changelog, effectively no upstream. Escalation path is internal: the wrapper's documented behaviour and our own tests. That is acceptable for an internal admin widget and unacceptable for anything customer-facing or compliance-relevant.

Scaling

Three axes to test, not assume:

• Data volume. Parent option queries at realistic cardinality — 10k+ categories is normal for large catalogs. If it is a flat select, it fails on load time and browser memory, and it fails gradually rather than loudly.
• Query amplification. Nova field resolve/relatable calls run per form render; confirm no N+1 on index views.
• Tree depth. Deep hierarchies stress whatever indentation/labelling the field does; verify no recursion or unbounded query.

Failure modes

Ramp-up

Low for anyone fluent in Nova fields — registration and Composer are well-trodden. The non-obvious cost is judgment under thin evidence: engineers must treat a 4-year-stale, 5-star field as untrusted, route all usage through our own field class, and push cycle-prevention and authorization into our domain layer rather than the widget. Put that in the ticket, or it will drift into direct dependency on the vendor's class.

Recommendation — Leverage it only as a spike, then most likely build. The package's entire value proposition is a parent select on a Nova form, which is a 1–2 day build against Nova's existing BelongsTo machinery — and the build gives us the authorization scoping, cycle validation, and searchability the package does not demonstrably provide. Use the package as a reference implementation during the spike: read how it wires the field, confirm the Nova 3-era assumptions, and then decide. Adopt outright only if (a) we are already on the Nova major it supports, (b) wamadev/parental is genuinely load-bearing and separately assessed, and (c) it is confined to internal, low-cardinality hierarchies behind a wrapper. Otherwise the asymmetric dependency — a stale dependency on a closed-source platform we must upgrade — is not worth a widget.