Nova Inline Relationship Laravel Package

Product Decisions This Supports

• Build vs. buy for internal admin tooling. Nova's default relationship handling sends operators off to a separate child resource screen to read or edit a related record, then back. This package collapses that round trip into an inline field and a modal on the parent form — a one-line field swap rather than a sprint ticket. Treat it as an accelerator for existing admin work, not a platform commitment.
• Roadmap allocation for back-office/ops surfaces. A concrete, low-cost lever for the recurring "our admin is slow to use" request. Bundle it into a small admin-UX workstream alongside filters, metrics, and bulk actions; it buys measurable operator time back without pulling engineers off customer-facing work.
• Feature scoping for data density in index views. Because related attributes render inline instead of as separate columns or drill-downs, it forces an explicit answer to "how much related context fits in one row before we split the view?" — a constraint that otherwise gets negotiated ad hoc, resource by resource.
• Whether admin editing belongs on the index at all. The consequential capability is the inline update path: it turns a list view into a write surface. Speed vs. accidental-edit risk, audit trail, permission granularity, timestamp and cache side effects — that is a product decision to make deliberately per field, not one to inherit by dropping the field in and discovering writes in production.
• Consolidating bespoke admin code. If resources already carry a dozen Text::make(..., fn () => $this->relation->attr) closures, this is a refactor, not a new capability — with a clean success metric: no hand-rolled inline-field closures left in the codebase.
• Vendor and dependency evaluation inside the Nova ecosystem. Kirschbaum is a recognized Laravel/Nova shop, and MIT licensing keeps the fork option open. This is a low-commitment test of whether third-party Nova fields belong in the internal-tooling stack before standardizing on more of them. The 2.1.1 timestamps patch is a modest but real liveness signal at a slow release cadence.
• Whether to keep investing in Nova. The package's value is gated entirely on Nova usage. A healthy field ecosystem is one modest input to the renew/expand-Nova question — not a reason to choose Nova, but a data point on ecosystem depth.

When to Consider This Package

Consider it when:

• You are committed to Laravel Nova (4.x/5.x — verify the installed version against the package's composer.json constraint before committing; the last release predates widespread Nova 5 deployment, so treat Nova 5 as untested until the field renders in a browser).
• The pain is repeated and specific: multiple Nova resources where operators need one or two related attributes visible on the index and today they either click through or maintain scattered resolveUsing closures.
• Read-only is the primary job and inline editing is a governed bonus. Inline display of a related property is the core use case. The write path is real, so enable it per field with intent — validation rules, policies on the related model, and a named list of editable attributes.
• The integration surface is small and reversible. One composer dependency plus a field class per resource; removal is a refactor measured in hours, not a migration.
• You can absorb patch-level maintenance. The 2.1.1 fix (respecting $timestamps on the related model when saving inline) was a data-integrity fix, not cosmetics. Budget for reading each changelog manually rather than letting composer update decide.
• Your index endpoints are already under control on N+1. This field lazy-loads per row unless the resource declares $with or indexQuery eager loading. Ten rows looks fine; five hundred rows is a latency ticket.

Look elsewhere when:

• Nova is not the admin stack, or the team is mid-migration off Nova — the entire value proposition is gated on Nova's field system.
• Operators will immediately need sorting, filtering, or search on the inline attribute. This is a presentation-layer field only; if sortability is the first follow-up ticket, plan a real column or custom field instead.
• The related model has a complex or sensitive edit surface (multi-step validation, side-effecting observers, approval workflows). Inline editing in a table row is the wrong interaction for that.
• You need a guaranteed-compatible, actively maintained dependency with SLA-style support. 193 stars, zero dependents, and a slow release cadence mean the realistic fallback is forking — MIT permits it, and the PHP field class is small.
• The related model's policy would block the equivalent edit on its own resource screen. Nova authorizes against the parent resource; editing a child through the parent should not become a policy bypass, and if you cannot verify both layers, defer the write path.

How to Pitch It (Stakeholders)

To executives: This is a small, reversible addition to our internal admin tooling that removes repeated click-throughs for the operations team. It is a composer dependency plus a few lines of resource code — hours of work, not a sprint — and it addresses a recurring "the admin is slow to use" complaint without taking engineers off customer-facing priorities. Cost is near zero; downside is contained because removal is a refactor, not a migration.

To engineering: Ship it in two phases. Phase one is read-only inline display of related attributes on index views — near-zero risk and where most teams should stop. Phase two is inline editing, which converts an index table into a write surface; that phase gets its own review covering validation, related-model policy authorization, audit trail, accidental-edit risk, and side effects from model events and updated_at. Wrap the package field in our own class (RelatedAttribute::make(...)) so a Nova major upgrade, upstream stall, or swap to a fork is a one-file change instead of a sweep across a dozen resources. Declare eager loading on every resource that uses it and prove it with a query-count test — N+1 is the default failure mode and development hides it. Pin ^2.1.1 (2.1.0 mishandled $timestamps on inline saves — a write-path integrity bug in an admin surface), and add tests covering null relations, populated relations, and a $timestamps = false child so a future dependency bump cannot quietly undo the fix. Nova majors are the maintenance cliff and the package's semver will not warn us; keep the wrapper and treat a fork as a realistic fallback rather than a last resort. Record the semantics in our Nova style guide: this field may write to the related model — verify policy and timestamp behaviour before using it.