Nova Inline Text Field Laravel Package

Technical Evaluation

Architecture fit. This is a single-purpose Nova field, not a subsystem: one PHP field class plus a Vue component, no config file, no migration, no service to operate. For a TPM that is the entire architectural argument — the integration surface is one line in a resource's fields() and the blast radius is one column on one admin screen. It fits wherever Nova already owns the admin surface; it does not fit anywhere else. There is no path to reusing it in a customer-facing UI, and attempting that is a scope error, not an engineering challenge.

The one thing to resolve before anything else. Our sources disagree on what the package is. The description and PM notes describe inline editing from the index (click, type, AJAX save). At least one internal review reads it as a display-only presentation helper. These are different products: an editable field raises validation-bypass, authorization, and audit-trail questions; a display-only field raises essentially none. This is a half-day of reading src/InlineText.php end to end plus one field on a scratch resource — and it gates every risk statement below. Do not let a plan, a sprint commitment, or a stakeholder expectation get built on the wrong reading. Treat the resolution of this ambiguity as a named deliverable with an owner, not a background assumption.

Integration feasibility. Feasible and cheap if the prerequisites hold: Nova 4.x or 5.x, Laravel 10/11, PHP 8.1+. The real cost is not the package — it is Nova's private Composer repository credentials in both local and CI. Budget roughly a day for credentials, first install, and a boot smoke test. The composer require itself is minutes. Teams on Nova 3 or Laravel 8 would need the 2.x line, which is a different major and a different review; do not silently mix majors across a fleet of panels.

Technical risk. Three risks, ranked:

1. Boot-time fatality from a closed-source coupling. 3.0.1 is itself a hotfix for an InlineText method incompatibility with its parent Nova class — in PHP that is a "declaration must be compatible" fatal at class load, which takes down the whole Nova panel rather than degrading one field. The package overrides Nova internals, and Nova ships on its own cadence with no upstream changelog we can diff against. Breakage surfaces after a Nova upgrade or in production, never during our code review. Mitigation is procedural, not technical: pin ^3.0.1 (never 3.0.0), gate Nova upgrades behind staging, and add a request-level boot smoke test to CI.
2. Write-path correctness, if it is in fact editable. Two questions determine whether this is safe: does the inline save enforce Nova validation rules and authorizedToUpdate? Does it fire Eloquent events? If either answer is no, observers, activity logs, audit tables, and search indexes drift silently, and the divergence compounds with usage volume. Enforce rules on the field and policy on the endpoint regardless of the answer, and keep a model-level observer as an audit backstop.
3. Bus factor. 23 stars, 0 dependents, a small maintainer team, GitHub issues as the only support channel. Classify it as a convenience dependency, not infrastructure. The saving grace is that the small surface area makes fork-or-replace genuinely cheap — protect that by not letting usage sprawl across twenty resources before the first one proves out.

Key questions to close before approval.

• Editable or display-only? (Gates everything below.)
• Which Nova major are we on, and is it the same major across all panels that would adopt this?
• Do we have Nova Composer credentials in CI today, and who owns their rotation and expiry?
• Does the inline save path enforce Nova validation and authorizedToUpdate?
• Does the inline save path fire Eloquent events — and if not, what is our compensating control?
• Is sortable() honored on the field, and do we need it on any candidate column? Read the class before promising it in a spec.
• Who owns the fork-or-replace decision, and what signal triggers it (e.g. a Nova major with no compatible release after N weeks)?

Integration Approach

Stack fit. Nova field, Nova panel, Nova-adjacent resources only. Confirm the FQCN from src/ before writing code — the vendor namespace (optimistdigital) and the GitHub org (outl1ne) have diverged, and the class name is not always obvious from the repo name. There is nothing to publish: no config, no migration, no vendor:publish step. If someone is hunting for a config file to tune, the answer is that the field class is the config.

Migration path. There is no migration in the data sense — no schema change — but there is a behavioural migration: the moment an inline field goes live, the ops workflow for that attribute changes from "open record, edit, save" to "edit in the table." Scope that deliberately. Start with one low-traffic resource and one short single-value string: a display name, label, title, or status line. If a field is currently edited through a form that performs side effects (slug generation, cache invalidation, notifications, denormalized column updates), it is not a migration candidate — those belong in a later tranche or not at all.

Compatibility.

• Pin ^3.0.1. Never adopt 3.0.0; if it appears in a composer.lock, that is a patch to ship today, not next sprint. Add it to the dependency-review checklist.
• Verify the field renders under our specific Nova minor before scoping beyond the pilot. Asset-pipeline failures look like blank fields — clear compiled views and re-run php artisan nova:publish, and check the browser console before touching PHP.
• Validate against the Nova version in staging, not just the version we read about.

Sequencing.

1. Confirm the product (editable vs display-only) on a scratch resource. Half a day, blocking.
2. Credentials and boot smoke test — get Nova's private repo resolving in local and CI, then load /nova in an empty panel before adding any field. A fatal here should be found in a bare panel, not on a resource page.
3. Build the wrapper, not a subclass. A small static helper returning a configured InlineText gives us one place to swap the package for a ~100-line custom field if it goes stale. Subclassing inherits the exact fragility the 3.0.1 fix was repairing, on every Nova minor bump.
4. Pilot on one resource, behind a config flag or feature toggle, so a single field can be disabled without a revert.
5. Run the four-path test matrix on that resource: index render, successful save, validation failure, policy denial (403).
6. Measure before expanding: median time-to-complete-edit and clicks-per-edit, before and after. Fund the second tranche on evidence, not intuition.
7. Add CI coverage: a request test that hits /nova as an authenticated user (a fatal at class load is not catchable by a unit test but is catchable by a request test), plus a feature test POSTing to the Nova update endpoint asserting both happy path and 403.

Placement conventions worth standardising early. ->onlyOnIndex() for high-frequency edits, ->onlyOnDetail() where the value is informative but shouldn't be inline, both by default only when the blast radius is genuinely low. Encode these in the wrapper so the convention is enforced by code rather than by review comments.

Operational Impact

Maintenance. Near-zero on our side in the happy path; the maintenance burden sits with a small upstream team on someone else's release cadence. Our obligations are: keep the wrapper thin, keep the version pinned, keep the boot smoke test in CI, and keep a fork-or-replace note in the repo with a named owner. The cost we actually carry is re-validation on Nova upgrades — treat "we upgraded Nova" as a change that requires re-running the four pilot paths in staging. This is the single recurring operational cost of adoption, and it scales with how many resources use the field, not with how many teams do.

Support. GitHub issues only. No SLA, no vendor channel, no commercial backing. That is acceptable for a convenience dependency on an internal admin surface and unacceptable for anything the business depends on at runtime. Say this out loud in the adoption record rather than discovering it during an incident. Internal support cost is low but not zero: whoever owns the wrapper owns the triage when a field goes blank or a save silently no-ops.

Scaling. Scales fine in the dimension that matters here — a handful of fields across a handful of resources. It does not scale in two directions: breadth (usage across many resources multiplies the re-validation cost per Nova upgrade and multiplies exposure to the bus factor) and complexity (rich text, long-form content, validation-heavy workflows, multi-field inline editing are explicitly out of scope — stretching the field there is where the risk lives). Cap the initial footprint deliberately. The correct posture is a narrow, well-understood tranche of commodity edits, not a campaign to inline-enable the panel.

Failure modes and their signatures.

• Panel-wide fatal at class load (PHP declaration-compatibility). Highest severity, lowest detection cost — caught by a boot smoke test hitting /nova in CI and by the staging pass on every Nova upgrade. This is the reason 3.0.1 is the floor.
• Silent save with no visible change. Usually an attribute-name mismatch between the field and the model, or a policy quietly denying the update. Debug by finding the update endpoint (php artisan route:list | grep nova), reading the JSON response body in the network tab, and confirming the field's attribute matches the model attribute exactly.
• Silent drift in derived state. If the inline path bypasses Eloquent events, observers, activity logs, search indexes, and cached aggregates fall out of sync — invisibly, and cumulatively with usage. This is the failure mode that argues hardest for keeping the field away from fields with downstream derived state and for keeping a model-level observer as an audit backstop.
• Blank field after an upgrade. Usually compiled assets, not the field definition. Clear compiled views, re-run php artisan nova:publish, check the console.
• CI failure on a fresh runner unrelated to our code. Check Nova repository auth before checking the diff.

Ramp-up. Low for engineers who already know Nova — one line in fields(), familiar field configuration, no new mental model. The ramp-up cost is concentrated in platform work rather than developer learning: Nova Composer credentials in local and CI, documented and cached deliberately with an owner and an expiry plan; the boot smoke test; the wrapper; the staging gate on Nova upgrades. Budget roughly a day for that platform work regardless of how many engineers use the field. The PM implication is that the first adoption should be funded as a small, measured pilot with a before/after metric attached — if the time-to-complete-edit improvement doesn't show up on the first resource, the honest answer is to stop at one field rather than roll it out and inherit the upgrade-revalidation cost across the panel.