Nova Fields Laravel Package

Technical Evaluation

Architecture fit. 64robots/nova-fields is a presentation-layer add-on, not infrastructure. It registers field classes into Nova's fields() contract via Laravel auto-discovery, ships precompiled Vue components, and requires no migrations, config files, or service providers of your own. That means it slots into the layer of your system with the smallest blast radius: the admin resource definitions. It does not touch models, jobs, APIs, or auth. For a TPM this is the ideal dependency shape — reversible, contained, and invisible to customers.

Integration feasibility. Low-friction on paper: composer require, pin the version, drop field classes into a resource, php artisan nova:publish, clear caches. The real feasibility gate is the laravel/nova constraint in the package's own composer.json — field packages are coupled to Nova's front-end contract, not to a public API, so that constraint is the single yes/no for whether this works on your Nova major. With a last release of May 2024 and effectively zero dependents, that gate must be verified manually before any commitment.

Technical risk. Three risks matter, in order: (1) Nova major drift — an upstream Nova upgrade without a matching package release produces blank fields and console errors silently in production admin; (2) write-transforming fields — currency/number normalization and slug generation change what lands in the database, and the failure mode is bad data written with no exception thrown; (3) Google Places — third-party API key, outbound browser calls, quota/billing exposure, and address data as PII. The first is a runbook item, the second is a data-audit item, the third is a separate go/no-go decision. Bus factor is one maintainer on an MIT license; the correct posture is "we may own the fork."

Key questions.

• Which Nova major are we on, and does the pinned release explicitly declare support for it?
• Which of the five fields do we actually need, and which are already covered natively by Nova core (searchable BelongsTo, formatted numbers, slug-ish inputs)?
• Do any adopted fields transform data on write, and who owns the before/after audit for those columns?
• Is the Google Places field in scope at all, or do we explicitly exclude it and use a plain text field?
• Who is the named internal owner empowered to fork and patch a Nova field when it lags?

Integration Approach

Stack fit. Fit is conditional and narrow: Laravel + a licensed Nova install + Composer. Outside Nova the package is inert; it is not a general Laravel form library. Inside Nova it is a convenience layer, and the TPM framing should be exactly that — "configure existing admin fields" rather than "adopt a framework extension." Keep it off any path that touches customer-facing surfaces, and off any path where admin UX is a differentiator.

Migration path. There is no migration in the database sense and none needed in the codebase sense. Adoption is per field, per resource, declared inline in fields(). The recommended path is: pin the version → pilot one display-only field in a single low-traffic internal resource → verify it renders on form, detail, and index with a clean console and a value that round-trips unchanged → widen to additional fields one at a time. Rollback is a one-line revert on one resource, which is the property that makes this cheap to approve.

Compatibility. Two constraints to track in parallel: the laravel/nova version constraint (the hard gate) and PHP/Laravel minor drift (a package untouched since mid-2024 will eventually lag a PHP minor). Pinning the package version is mandatory, not hygiene — floating constraints on front-end-coupled field packages turn every composer update into an unreviewed admin-panel change. Add "verify nova-fields against the new Nova major" as an owned line item in the Nova upgrade runbook, with a re-evaluation trigger if the package goes a full Nova major without a release.

Sequencing. Wrap, don't scatter. Declare fields through thin local factories (e.g., App\Nova\Fields\Money extends \NovaFields\Currency) so a future swap to a native field or an in-house component is a one-file change rather than a grep across dozens of resources. Layer domain behaviour — minor-unit normalization, tenant locale formatting, composite slug derivation — in the resource via resolveUsing/fillUsing, never inside package classes. Build each resource with native fields first, then reach for this package only where Nova leaves a genuine gap; if the desired list is mostly native, the correct outcome is one or two fields, not the bundle. Maintain a short docs/nova-fields.md inventory of which fields are used where, so the next engineer doesn't assume the whole bundle is sanctioned.

Operational Impact

Maintenance. The realistic operating model is "we own the fork." One maintainer, 283 stars, zero listed dependents means edge cases will be discovered by you, on your data, not by a community. Budget for a named internal owner, a pinned version, and a periodic dependency-review cadence that watches PHP and Laravel minors as well as Nova. All upstream fixes are bounded if the resource-layer wrapping discipline holds — an upstream break becomes a one-file patch, not an incident.

Support. No SLA, no security response process, MIT drive-by support. That is acceptable for internal admin widgets and unacceptable for anything with compliance weight. Do not route sensitive data flows through this package without a reviewed posture; the Google Places field is the clearest case and should be decided separately from the rest of the bundle, with a referrer- and API-restricted key if it is adopted at all.

Scaling. Scaling risk is not throughput, it is index-page query cost and field sprawl. Searchable/relatable fields can N+1 across 50 index rows — constrain them with relatableQueryUsing/withMeta() where supported, or keep them form-only and render a cheap accessor on the index. Field sprawl is a governance problem: without the inventory doc, adoption expands by accretion until a Nova upgrade becomes a multi-resource debugging exercise.

Failure modes. Ranked by how quietly they fail: (1) Nova upgrade mismatch — blank fields, missing props, console errors, discovered after deploy in the admin panel; mitigate with a runbook line item and post-deploy smoke check on pilot resources. (2) Silent bad writes — currency/slug/percent fields storing transformed values that validation didn't anticipate; mitigate with pre-rollout before/after audits on sample records, integer minor-unit columns for money, unique indexes for slugs, and a documented rollback. (3) Country code mismatch — existing rows holding names instead of CHAR(2) codes render blank on detail/edit and can be silently overwritten on resave; check column contents and length before adoption. (4) Component resolution failure — field renders as raw text or an empty div; fix order is browser console, then nova:publish and cache clears, then the class's component() value against dist/. (5) Quota/billing surprise from Google Places.

Ramp-up. Fast for engineers already fluent in Nova — roughly the cost of writing a normal field declaration plus a console check per field. The non-obvious ramp-up cost is the QA burden: with no dependent base, you are the compatibility test suite. Pilot on one display-only field in one low-traffic internal resource, define explicit success criteria (renders on form/detail/index, clean console, value round-trips unchanged), and only then widen. That sequence converts the package from an open-ended dependency into a series of small, reversible, individually-approved configuration changes — which is the only way a TPM should sign off on a single-maintainer admin bundle.