Nova Nested Many Laravel Package

Product Decisions This Supports

• Build vs. buy vs. fork for nested admin data entry. Editing parent → child → grandchild records in a single Nova form is typically a 3–10 day internal Vue/PHP build. This package converts that into a cheap, reversible spike, so the adopt/fork/build call gets made on observed operator behavior instead of an engineering estimate. All three outcomes stay open — and get cheaper to evaluate — once something working exists.
• Whether to keep the admin surface on Nova. "Native Nova can't edit nested hasMany records in one pass" is a common rationalization for an expensive bespoke back office. A working nested-many field removes that specific justification and keeps internal tooling on a stack the team already operates and pays for.
• Operator workflow and throughput design. The default Nova loop is create parent → open child resource → create grandchild → navigate back. Inline editing changes entry time, rework rate, and training cost for support and ops. A spike makes that UX decision against real usage rather than a mockup.
• Data modeling — normalize versus denormalize for UI comfort. When nested entry is painful, teams flatten schemas to make the admin form tolerable and pay for it later in reporting, migrations, and API shape. Cheap inline editing makes the clean, normalized model (orders → line items → add-ons) the defensible default.
• Entity scope boundaries. Adoption implicitly decides that a subset of child records live as editable rows inside a parent form rather than as first-class Nova resources with their own policies, search, filters, exports, and activity logs. That is a product decision about where the line between "form row" and "record" sits — make it deliberately, not by accident of tooling.
• Vendor and OSS risk posture. At 15 stars and zero dependents, "adopting" this is functionally a decision to fork and own source code. That is a standing policy question — do we vendor small OSS admin plugins, and who maintains them? — better answered once than re-litigated per package.
• Concrete workflows it unlocks: order → line items → add-ons; survey → sections → questions → options; CMS page → content blocks → block settings; bill of materials → components → sub-components; invoice → charges → adjustments. Anywhere an agent currently opens three tabs to enter one record.

When to Consider This Package

Consider it when:

• The stack is already Laravel + Laravel Nova. The Nova license is sunk cost; this is an incremental field, not a platform bet. Off Nova (Filament, Livewire/Inertia, Backpack), it has zero value.
• The domain genuinely has two or more levels of hasMany/hasOne that operators must author in a single pass — not one level, which Nova's native relationship fields already handle.
• The surface is internal and low-blast-radius: a handful of trained users, not customers, and not a revenue-critical flow.
• The team has PHP/Laravel capacity to read, fork, and maintain a few hundred lines of Nova field code. Treat MIT as permission to own the code, not a support contract.
• You are in discovery, MVP, or internal-tooling mode, where shipping the workflow this quarter beats waiting for a first-party solution.
• The realistic alternative is a custom Vue field anyway, in which case the package is a free head start on that build.

Look elsewhere when:

• You need a support contract, security review, or SLA. One maintainer, zero downstream dependents — your fork is the only maintenance guarantee.
• Nested collections are large. Inline forms hydrate every child eagerly; hundreds of rows per parent turns a UX win into a page-weight and transaction-length problem. If you can't cap the count, don't ship it on that relationship.
• Per-child authorization, audit trails, approval chains, or bulk operations are requirements. Those argue for first-class Nova resources, not inline rows.
• Cross-sibling validation or complex invariants dominate the domain; inline editors make those hard to express, test, and reason about.
• A Nova major-version upgrade is on the near roadmap. Small field plugins are the most common casualty of Nova 4 → 5 migrations; verify compatibility before committing.
• You need a stable API surface for other tooling or integrations. This is a UI convenience, not an integration point.

Recommended posture if adopted: time-box a spike (about two days); vendor the source into the repo behind your own field factory class; pin package version and Nova minor together in composer.lock; add feature tests for create-with-children, update-with-children, and child removal; ship behind a canSee()/config flag so rollout is reversible without a deploy. Budget one to two engineer-days per Nova major upgrade for the fork-and-rebase path.

How to Pitch It (Stakeholders)

To executives: This is a small, MIT-licensed UI component for the Laravel Nova admin panel we already run. It lets operators edit nested records — order line items and their add-ons, survey questions and their options — on a single screen instead of a multi-tab, multi-page entry loop. The business case is throughput and data quality: fewer rework cycles and fewer entry errors on exactly the kind of repetitive admin task that generates both. There is no license cost and no new vendor relationship, and the realistic alternative is several days of internal engineering to build the same field, so the pilot is cheap and reversible. Honest caveat: this is a very low-adoption package (15 stars, no downstream dependents). We should treat it as source code we adopt and own, not a dependency we rely on. Recommended path: a two-day spike, then vendor the code with a test around the save path — total cost stays well under building from scratch.

To engineering: It's a standard Nova field, drop-in via NestedMany::make(...), with no framework-level coupling and a codebase small enough to read end-to-end before merging. Before we commit, confirm three things: Nova 4.x vs. 5.x compatibility and that the shipped dist/ was built against our version; behavior under nested BelongsTo and non-super-admin policies, since inline child creates can bypass the normal resource path; and whether writes are transactional, since Nova doesn't wrap relationship field writes by default and this package issues multiple inserts per submit. Wrap it behind our own field class from day one so swapping or forking is a one-file change, keep the child resource registered and first-class for support, exports, and audit views, and write the create/update/delete-with-children feature test before it ships — that test is also what catches a Nova upgrade in minutes instead of in production.