Nova Nested Many Laravel Package

Technical Evaluation

Architecture fit. The package is a single Laravel Nova field: a PHP class that extends Nova's native HasMany field plus a compiled Vue component delivered through Nova's standard field-asset pipeline. It does not touch models, migrations, service providers of the host app, or the data layer — it renders the child resource's own fields() inside the parent resource's form and hydrates a HasMany payload on submit. That means the blast radius is confined to the admin UI: if the package is removed, the underlying schema, policies, and models are unchanged. For a TPM this is the important property — the architectural commitment is a UI convenience layer over an existing relationship, not a new abstraction the product becomes dependent on. Off Nova (Filament, Livewire/Inertia, Backpack, a bespoke admin), the package has zero value; the evaluation is only valid if Nova is already the admin platform and the licence is sunk cost.

Integration feasibility. Integration is genuinely small: composer require behind Nova's licensed Composer auth, one field line in the parent resource, and the child resource must already be a registered Nova resource so fields(), rules(), and policies resolve. There is no standalone build, no config file to publish in the common case, and no service to provision. The realistic work is not installation but three verification steps that a TPM should schedule explicitly: (1) confirm the shipped dist/ bundle was built against the team's Nova minor, since Nova 4 → 5 changed the field API; (2) walk create/update/delete of child rows as a non-super-admin to check that inline creates honour the child resource's createX policy; (3) force a mid-submit failure to establish whether the multiple inserts are transactional. Each is 30–60 minutes; together they are the difference between a one-day spike and a two-week surprise. Everything else — inline create/edit/delete, nested validation, two levels of nesting — is reported to work by adopters and is testable in the same session.

Technical risk. Risk concentrates in four places, all of which are manageable if named up front. First, maintenance risk: 15 stars, zero dependents, one maintainer. Adopting this is functionally a decision to fork and own the source, and the correct framing in any steering conversation is "source code we adopt," not "a dependency we rely on." MIT makes forking free, so fork before depending, not after. Second, version drift: the compiled Vue component is pinned to the Nova minor it was built against; a Nova upgrade without a rebuild against the new minor is the single most likely breakage, and rebuilding requires the Nova source tree plus a Node toolchain. Third, authorization bypass: inline nested create paths in Nova field packages frequently skip the child resource's createX check, which is a security-relevant defect in any admin surface with non-super-admin roles. Fourth, field-package collisions: multiple Nova field packages patching the same Vue components (conditional fields, dependency containers, custom BelongsTo overrides) break each other silently. Page weight is linear in child count, which is a UX risk rather than an availability risk but should be capped with a hard limit if the relationship can grow.

Key questions. These are the questions a TPM should have answered before approving anything beyond a spike: Which Nova major and minor are we on, and does the vendored dist/ match it? Is the child relationship one level or two — and are we comfortable that three levels is unproven? What is the realistic maximum child count per parent, and can we enforce it? Do non-super-admin roles exist for this resource, and has the inline-create policy path been tested for each? What is our standing policy on vendoring small MIT admin plugins — who owns the fork, and is there budget for 1–2 engineer-days per Nova major upgrade? And finally: is the alternative to this package a custom Vue field (in which case this is a free head start) or Nova's native two-step flow (in which case we are buying UX, and should measure it)?

Integration Approach

Stack fit. Appropriate only where the stack is Laravel plus Laravel Nova and the domain genuinely has two or more levels of hasMany/hasOne that operators author in one pass. One level of relationship is already handled natively by Nova's relationship fields; using this package there adds ownership cost for no gain. The strongest fit is internal, low-blast-radius tooling — a handful of trained operators, not customers, not a revenue-critical flow: order → line items → add-ons, survey → sections → questions → options, CMS page → content blocks → settings, invoice → charges → adjustments. Where per-child authorization, audit trails, approval chains, or bulk operations are requirements, inline rows are the wrong shape and first-class Nova resources are correct; that is a product decision about where the line between "form row" and "record" sits, and it should be made deliberately rather than inherited from whichever tool was easiest.

Migration path. There is no data migration — the schema is untouched. The migration is a UI cutover per resource, and it is reversible in one line. The recommended path: vendor the source into packages/nova-nested-many, add a path repository to composer.json, pin the commit, and wrap it immediately behind an in-house field class:

// app/Nova/Fields/NestedRelation.php
class NestedRelation extends NestedMany {}

Every resource calls NestedRelation, never the vendor class. That single indirection makes swapping to an in-house Vue field, or reverting to Nova's native two-step flow, a one-file change rather than a codebase-wide refactor — it is the highest-leverage action available on day one. Combine it with a config-driven visibility gate:

NestedRelation::make('Line Items', 'lineItems', LineItemResource::class)
    ->canSee(fn () => config('admin.nested_many'));

so rollout is pulled with a config revert, not a deploy. Keep the child resource visible in the Nova sidebar and fully first-class throughout — support staff still need it for bulk edits, exports, and audit views, and both surfaces sharing the same model and policies is a feature, not duplication.

Compatibility. Pin the package version and the Nova minor together in composer.lock and treat them as a unit. Verify the vendored dist/ build date and target Nova minor before the first form load; if they diverge, a local rebuild requires the Nova source tree and a working Node toolchain, which is a real scheduling dependency rather than a footnote. Audit other Nova field packages in the same resources the first time the form loads, because mixins on shared Vue components collide silently. Nested fields should stay boring: text, number, select, date, boolean, and a plain BelongsTo to a small lookup table all behave; file/MediaLibrary uploads, searchable BelongsTo, and computed fields inside a nested row are the known breakage points and should be added one at a time, in isolation. Nested BelongsTo specifically inherits viaResource/viaRelationship from the outer context, so scoped queries and searchable selects behave differently than at top level and must be tested before being relied on.

Sequencing. A time-boxed spike is the right first commitment, not an adoption decision. Suggested order: (1) confirm Nova licence credentials work in local and CI Composer auth; (2) install, publish, and load one form with scalar child fields behind a flag; (3) run the full round trip by hand — create parent with two children, edit one, delete one, submit with a deliberate child validation failure and observe where the error lands; (4) repeat steps 3 as a non-super-admin in the same session; (5) write the feature test — create-with-children, update-with-children, child-removal — before anything ships; (6) vendor and wrap behind NestedRelation; (7) roll out one resource at a time behind the config flag, with the child resource remaining accessible standalone. Steps 1–5 should fit in two engineer-days. Any finding that pushes past that — dist/Nova mismatch requiring a rebuild, a confirmed authorization bypass, non-transactional writes needing a DB::transaction wrapper at the action level — should return to the TPM as a scope decision rather than being absorbed silently.

Operational Impact

Maintenance. Assume unmaintained by default and plan accordingly. The steady-state cost is modest but non-zero: the fork lives in-repo under the team's own review and release process, and a budget of 1–2 engineer-days per Nova major upgrade (fork-and-rebase) is realistic and should be carried explicitly in planning rather than discovered during the upgrade. The codebase is small enough — a field class plus a compiled bundle — to be read end-to-end by the owning engineer before merge, which is the cheapest possible insurance and should be a condition of adoption. Assign a named owner for the fork at the outset; "the team owns it" reliably means nobody owns it by the second Nova upgrade.

Support. There is no support contract, no SLA, and no security review to lean on: one maintainer, zero downstream dependents, your fork is the only maintenance guarantee. That is acceptable for internal, low-blast-radius tooling with trained operators and unacceptable for anything customer-facing or revenue-critical, and the distinction should be stated plainly in the adoption record rather than left implicit. Support load also lands on the operators: keep the child resource first-class in the sidebar so support staff have a familiar fallback for bulk edits, exports, and audit views when the inline form is not the right tool for the job. Document the three known blank-form causes — child resource not registered, JS asset not published or provider not auto-discovered, dist/ built against the wrong Nova minor — so first-line triage does not escalate to engineering by default.

Scaling. Scaling limits are page weight and transaction length, both linear in child count, because the field hydrates every child eagerly. For relationships with a bounded natural size (line items on an order, sections in a survey, blocks on a page) this is fine and improves with usage. For relationships that can accumulate hundreds of children per parent, it degrades from a UX win into a slow form and a long write: if the count cannot be capped, this package should not ship on that relationship. Look for and use any limit-style option as a hard guardrail rather than a nicety, and treat the number of operators as a second scaling axis — this is designed for a handful of trained users, not a broad or external audience. Scaling across resources is cheap (each adoption is one field line), so breadth is fine; depth per parent is where the constraint lives.

Failure modes. The realistic failures, roughly in order of likelihood: version drift after a Nova upgrade (blank or broken form); mixins colliding with other Nova field packages on the same Vue components; authorization bypass on inline child creates for non-super-admin roles; non-atomic writes, since Nova does not wrap relationship writes in a transaction and this package issues multiple inserts per submit, so a mid-submit failure can leave a partially written parent; misplaced validation errors, where nested ->rules() enforce correctly server-side but the client-side error placement is the weak spot; and page degradation at high child counts. Mitigations map one-to-one: pin package and Nova minor together, rebuild dist/ as part of every Nova upgrade, audit co-installed field packages on first load, wrap saves in DB::transaction at the action level or force a failure to verify the package's own path, test invalid submissions explicitly, and cap child counts. The single most valuable artifact across all of these is the feature test walking create-with-children, update-with-children, and child-removal — it catches a Nova upgrade in minutes instead of in production, and it is the difference between a fork the team can maintain and a fork the team is afraid of.

Ramp-up. Operator ramp-up should be short — the form looks like the parent resource, which is the point — but it is not zero, because inline editing changes entry time, rework rate, and training cost for support and ops staff, and the error-placement weakness means invalid submissions look different than operators expect. Plan a short walkthrough plus a written fallback to the standalone child resource for the first cohort. Engineering ramp-up is a half-day of reading plus the spike; the constraint is not comprehension but ownership willingness, which should be settled before the first resource ships. The wider organisational ramp-up is the policy question this package forces: do we vendor small MIT admin plugins, and who maintains them? Answering that once — with this package as the precedent — is cheaper than re-litigating it per package, and it is the durable decision that outlasts the specific workflow this field unlocks.