Nova Nested Form Laravel Package

Product Decisions This Supports

• Build vs. buy vs. fork for admin tooling. This package answers "do we hand-roll a nested-form field in Nova, or start from OSS?" With 239 stars, a single maintainer, zero dependents, and a last release of May 2021, the honest answer is spike on it, then budget a fork — not adopt as a dependency. That framing forces the decision to account for total cost of ownership instead of just "free on Packagist."
• Where admin UX investment actually pays back. Inline nested editing earns its keep only where one parent owns an ordered set of children with their own attributes: orders + line items, invoices + charges, quotes, product variants, CMS pages + blocks, event sessions + tickets. If those flows drive admin support tickets or manual rework, this belongs on the roadmap. If admin is mostly flat CRUD, it doesn't.
• A measurable cycle-time bet. Collapsing "create parent → navigate → create each child → go back" into a single save is a claim you can attach to an OKR: fewer abandoned drafts, fewer orphaned children, less context switching. Treat it as a testable product hypothesis with a before/after time-to-complete, not a UI nicety.
• Native-first vs. extension-dependent admin strategy. Nova ships first-party relationship handling that covers part of this ground. Deciding whether the admin layer leans on third-party extensions or first-party primitives is a platform call that sets precedent for every future admin feature — far bigger than this one field.
• A migration trigger. A Nova 3-era codebase, a 2021 release, and no downstream dependents together define a ceiling. That informs three linked decisions: pin the admin stack, own a fork, or treat the admin layer as a candidate for a longer-term move to a stack where nested/repeater forms are native.
• Risk posture for internal tooling. The package is best evaluated as internal, low-blast-radius tooling. Deciding where on the customer-facing-to-internal spectrum this lands is itself the decision — it changes how much of the risk below you're willing to accept.

When to Consider This Package

Consider it when all of these hold:

• You are on Laravel Nova 3, or can verify compatibility on a throwaway branch. The 2021 component targets Vue 2; Nova 4/5 ships Vue 3, so support is unlikely without patching.
• The surface is internal, low-blast-radius admin, where a broken field degrades an internal workflow rather than a customer-facing product.
• Your dominant data-entry pattern is genuinely nested — one parent, ordered children with their own attributes — and users currently pay a multi-screen tax to enter it.
• You have capacity to fork and own the field. The code surface is roughly one PHP class and one Vue component, which makes owning it cheap; passively consuming it is what's expensive.
• You need the behavior in weeks, and the realistic alternative is one to three weeks of custom Nova field work plus its own maintenance tail.

Look elsewhere when:

• You are on Nova 4/5, or an upgrade is on the roadmap within the next two quarters. The port likely costs more than the feature is worth, and the failure mode is quiet: the field renders nothing, the nested key is dropped from the payload, the save appears to succeed, and every child row is deleted.
• You need per-child authorization. Child policies are generally not evaluated — anyone who can edit the parent can typically create and delete children. That's a hard blocker for multi-tenant, regulated, or externally-facing admin.
• The data model is polymorphic-first or pivot-heavy. BelongsToMany with meaningful pivot columns (quantity, role) isn't a first-class path here; model the pivot as a first-class child with two belongsTo relations instead.
• You need more than two levels of nesting, drag-and-drop ordering, or file uploads inside child rows — all are either absent or fragile.
• Atomicity is non-negotiable and you can't add it at the HTTP layer. The field performs N child writes in one request without guaranteeing a transaction. A middleware wrapper is cheap, but if your stack can't accommodate it, walk away.
• The child records are commercially or legally significant (financial line items, audit-relevant records). Omitted children are deleted on save with no confirmation — so soft deletes, a deleting observer, and an audit log become prerequisites, not nice-to-haves.

How to Pitch It (Stakeholders)

For executives — the one-paragraph version. Our admin users currently create parent records and their child records across multiple screens, which is slow and produces half-finished data. This open-source Nova field collapses that into one form and one save. The build-vs-buy math is favorable: one to three weeks of custom work avoided, for a spike plus an ongoing fork we own. But it is a four-year-old, single-maintainer package that only works on Nova 3 — so we're proposing to adopt-and-own it, pinned and forked, on internal admin screens only. Not a strategic dependency, and not on any customer-facing surface.

For engineering — the operating constraints. Treat this as a Nova 3 playbook. Install pinned with an explicit version constraint and a committed lockfile. Keep NestedForm on onlyOnForms() and native HasMany on onlyOnDetail() so the two never fight over the same attribute. Extract child field definitions into a class we own so swapping the vendor namespace for App\Nova\Fields\NestedForm is a one-line change. Wrap Nova writes in a transaction middleware. Add soft deletes plus a deleting observer that logs actor, parent, and payload — that single pattern converts silent data loss into a recoverable, investigable event. Write the HTTP-level test that submits one of two existing children and asserts what happened to the other; that test is our living spec for delete semantics and the thing that catches a regression after any fork.

What we're explicitly not claiming. We're not claiming Nova 4/5 readiness, per-child authorization, reliable sortable ordering, or robust file uploads inside nested rows. Each of those is a documented gap with a workaround, and each workaround is scoped as part of the estimate — not discovered later. The deliverable includes a one-page runbook covering delete semantics, authorization behavior, transaction wrapping, and escalation, written during the spike rather than after rollout.