Nova Grouped Field Laravel Package

Technical Evaluation

dillingham/nova-grouped-field is a Laravel Nova custom field that merges several related record attributes into a single displayed column with a configurable separator. It is a presentation-layer convenience for internal admin tooling, not a product capability — it touches no domain model, persistence, migration, or customer-facing surface. The TPM decision reduces to a single trade: depend on ~50 lines of third-party formatting code, or write the equivalent field in-house.

Architecture fit

• Zero coupling to models, jobs, or business logic. It lives entirely inside a Nova resource definition, making it near-totally reversible — removal is a one-line change.
• Only meaningful on Laravel + Laravel Nova. Nova is a separately licensed, paid product, so this is a decision made inside an existing Nova commitment, never a reason to adopt Nova.
• Its value is substitution: replacing duplicated Text::make() columns or displayUsing() closures with declarative config. No new capability — less column sprawl and cleaner rendering of partially filled rows.

Integration feasibility

• Standard composer require plus field registration in a resource. No service provider wiring, queues, cron, or infrastructure change. A Nova-fluent developer can stand it up in under an hour.
• Release 0.11 is additive: date formatting (PR #9), line-break separators (PR #8), and separator suppression on empty fields (PR #7). No removals or renames — a release-notes inference, not a guarantee under 0.x conventions.
• The empty-field fix is the highest-value item operationally. Dangling separators (Acme — — Amsterdam) read as corrupted data to admin users and generate internal support noise — the single strongest reason to take the dependency rather than hand-roll.

Technical risk

• Staleness is the headline risk. Last release 2020-01-12, 40 stars, single maintainer, zero dependents. The risk is silence, not churn — no declared compatibility with Nova 4/5, modern Laravel, or PHP 8.x.
• Nova internals dependency. Nova's field API has moved across majors. With no supported-version matrix declared, compatibility with your Nova major is the primary unknown and the first thing to verify.
• Pre-1.0 semantics. Minor bumps may carry breaking changes by convention. Pin exactly.
• Formatting edge cases. Date formatting applied to non-Carbon values and separator escaping (newline vs. <br> vs. plain text) across index vs. detail renderers are unverified behaviors that surface as visual bugs, not exceptions.

Key questions

1. What Nova / Laravel / PHP versions does the 0.11 composer.json declare, and does the field actually render on our Nova major?
2. Does our Nova license tier and upgrade cadence put us on a version this package predates?
3. Does date formatting degrade safely on non-date values, and how are separators escaped in index vs. detail contexts?
4. Is there coverage for all-empty groups (blank vs. placeholder vs. stray separator)?
5. Does it support index, detail, and inline-edit/preview contexts, or is it display-only?
6. What is our fork-and-vendor cost if the maintainer never returns? (Answer: low — small code surface.)

Integration Approach

Stack fit

• Drop-in for an existing Laravel + Nova admin surface; no runtime dependency beyond Composer. Appropriate precisely where teams already duplicate attributes across columns or maintain per-resource display closures.
• Explicitly out of scope: the customer-facing product, any non-Nova admin stack (use Filament's first-party stacked TextColumn instead), and any need for interactive grouped cells (per-segment links, badges, copy-to-clipboard) — that hits the package ceiling immediately.

Migration path

• No data migration. Display-only, so rollback is trivially safe.
• Incremental swap per resource: replace the existing Text::make() set (or displayUsing closure) with one grouped field, diff rendered output against the incumbent, then delete the old columns. Keep prior definitions in version control as the rollback artifact.

Compatibility

• Pin 0.11.x exactly; do not float. Given the 2020 last release, assume no forward compatibility with any Nova upgrade and re-validate on each Nova major.
• Confirm the specific Nova major in use before piloting, and verify behavior across index, detail, and any inline-edit contexts operators rely on.

Sequencing

1. Compatibility spike (½ day). Read composer.json and README, confirm Nova/Laravel/PHP support against our stack, render the field in one low-traffic resource.
2. Pilot (1–2 days). One resource exercising all three 0.11 behaviors: a date attribute with formatting, a multi-value group with a line-break separator, and a group with nullable attributes. Screenshot and diff against the incumbent.
3. Rollout. Resource by resource, each an independent revertible change. Start where optional fields make the empty-separator fix visible.
4. Document. Record the pinned version, assumed Nova version, and separator/format conventions so contributors don't diverge. Isolate usage inside resource definitions so a swap to a custom field stays contained.

Operational Impact

Maintenance

• Low ongoing cost — display-only, no schema side effects, no background processes, and no query changes when grouped attributes are already columns on the loaded model.
• The real maintenance work is dependency hygiene, not code. A 2020-frozen, single-maintainer, pre-1.0 package will fail strict SBOM / security-review / maintenance-SLA bars. Acceptable for internal admin tooling; not for anything customer-facing.
• Budget a fork contingency up front. The surface is small enough to vendor a stable copy — that is the hedge that makes staleness tolerable, and it should be priced in hours, not weeks.

Support

• Community-only (GitHub issues), no vendor SLA, no recent activity. Support ownership must sit with the team that owns the Nova admin panel, not a central platform team.
• Escalation is effectively "we fix it or we replace it." Decide which before adoption, not after: a custom field in-house is the replacement path, and it is cheap.
• Treat adoption as a reversible experiment owned by the admin-panel team, with a documented exit (replace with a custom field or accessor-plus-stock-field) that stays under one sprint.

Scaling

• Scales with the admin panel, not with customer traffic — negligible runtime cost, no new load on the core application.
• Watch N+1: grouping relationship-backed attributes onto an index view without eager loading will multiply queries. Constrain grouped fields to columns already on the loaded model, or verify with() coverage.
• Grouping trades away per-column sort/search. If operators need to sort or filter on a group member (e.g., by email), grouped display fights them — keep those attributes as standalone columns.

Failure modes

• Visual-only degradation: formatting edge cases (date applied to non-dates, separator escaping mismatch) produce ugly output, not exceptions — low blast radius, high noise.
• Nova-major incompatibility: the field fails to render or errors on upgrade. Contained to admin views; no customer impact.
• Abandonware: no upstream fixes ever. Mitigated by pinning, vendoring, and keeping usage isolated.
• Corrupted-looking data: the empty-separator artifact class, addressed by 0.11 — verify it before relying on it.

Ramp-up

• Minimal. Nova developers recognize the fluent Grouped::make()->fields([...]) API immediately; the package mirrors native field conventions.
• Ramp cost is verification, not learning: confirm compatibility, behavior across render contexts, and conventions — that is the spike, and it is the only real onboarding work.
• Document separator/format conventions in the admin-panel docs so contributors don't diverge; without that, grouped fields drift into inconsistent styling across resources.

Bottom line for the TPM: This is admin-panel polish with near-zero exit cost and no product risk. Approve it as a time-boxed, reversible experiment inside an existing Nova commitment — gated on a compatibility spike against our Nova major, pinned exactly, with a fork/vendor contingency already priced. If the spike turns awkward, the fallback is a computed accessor plus a stock Nova field in under a day of engineering.