Nova Resource Field Laravel Package

Product Decisions This Supports

• Build vs. buy for internal admin tooling. advoor/nova-resource-field is a small Nova field that lets you compose a related resource's fields directly into a parent resource form. Adopting it replaces roughly 2–5 days of custom field work (form schema wiring, fill/dehydrate/save hooks, validation passthrough) with a Composer require. At a 0.x maturity level, the honest framing is "buy a head start, budget a fork," not "buy a supported dependency."
• Feature: inline/nested resource editing in the back office. Enables workflows where an operator edits a child record without leaving the parent screen — e.g. editing a location's address record alongside the location, or managing a small set of line items on an order. This is a UX velocity decision: fewer clicks and fewer context switches for ops staff, measurable in task completion time if the admin is used daily.
• Roadmap: admin/internal tooling track, not the customer product. Treat this as an enabler on the internal-tooling roadmap. It should not gate customer-facing commitments; it can be swapped or replaced with a hand-rolled field without user-visible impact.
• v0.3 changes the calculus in two concrete ways. (1) Custom settings per field means configuration is no longer effectively global per field type — you can now instantiate the field multiple times on one form with different behavior (different source resource, display mode, or save strategy). That moves the package from "single-purpose convenience" to "reusable primitive," which unlocks more of the backlog without a fork. (2) The release closes an external contributor's issue (#1), a modest but real signal that the maintainer is responsive — worth weighting when judging abandonment risk.
• De-risking decision this release does not settle. It is still a 0.x package with a single maintainer, thin release notes, and no visible test or migration guidance. The PM decision is therefore "adopt behind a pinned version, with a named internal owner and a fork budget" rather than "standardize on it."
• Opportunity-cost check. If the team is on Filament or building greenfield admin, the equivalent capability is native or better-supported; adopting Nova-specific glue would lock the roadmap into a paid, license-gated ecosystem.

When to Consider This Package

Consider adoption when:

• Laravel Nova is already the sanctioned admin stack and the license is paid — this is an additive field, not a platform bet.
• You have a concrete, near-term need for editing a related resource's fields inside a parent form, and the alternative is a bespoke Nova field.
• Configuration-per-instance matters to you (the v0.3 capability) — e.g. reusing the same field across two different relations on one form.
• The team is comfortable pinning to an exact 0.x version, reading the field's source before upgrading, and owning a fork if the maintainer goes quiet.
• The blast radius is internal staff, not customers — a regression is annoying, not revenue-affecting.

Look elsewhere when:

• You need vendor support, SLAs, security backports, or a documented deprecation policy. At 0.x with sparse release notes, none of that is on offer.
• Nested editing involves complex relationship semantics — polymorphic relations, pivot data, deep validation, authorization per child record, or transactional multi-model saves. Verify these against the source first; a small field package is unlikely to cover them, and discovering this mid-sprint is the expensive failure mode.
• The admin is multi-tenant with per-tenant field configuration or heavy permission scoping; per-field settings are static PHP config, not runtime-resolved policy.
• You are not on Nova, or are evaluating a move to Filament / raw Livewire. Don't let a convenient field become the reason to stay.
• You require reproducible dependency policy (lockfile auditing, no unmaintained transitive packages) at organizational scale.

Minimum adoption checklist: pin the exact tag, read the diff for v0.3 before bumping, add a feature test that exercises the field on your highest-traffic form, and record a fallback plan (fork under the org namespace) in the tech-debt register.

How to Pitch It (Stakeholders)

For executives: We are evaluating a small, free add-on for our existing Nova admin panel that lets staff edit related records without leaving the page. It removes an estimated few days of custom development and improves day-to-day efficiency for back-office users. The cost is zero in license terms; the risk is maintenance — it is an early-version (0.x) community package with one maintainer. We mitigate that by pinning the version, owning a fork if needed, and keeping it confined to internal tooling so no customer-facing commitment depends on it. Recommendation: adopt narrowly on one workflow, review in a quarter. No incremental spend requested.

For engineering: v0.3 adds per-field custom settings, so the field can be configured independently each time it is used on a form — this is what makes it a reusable primitive rather than a one-off. The change reads as additive and low-risk, but at 0.x you should diff the tag rather than trust the release note, which is a single line. Actions: pin the version, add one integration test covering the parent/child save path and validation passthrough, and confirm behavior for polymorphic and pivot relations before committing to broader use. If the maintainer stalls, the fork surface is one field class — cheap to absorb. Do not extend it into authorization or transactional multi-model saves without a spike.