Nova Fields Laravel Package

Product Decisions This Supports

• Build vs. buy for internal admin tooling. Nova is already a paid, licensed admin framework; this is a free MIT bundle of precompiled field components that fills the gap between Nova's stock fields and what operators actually need — boolean toggles with human labels, formatted currency, bounded number/percent inputs, date ranges, rich-text, plus source-level extras like slug generation, country selectors, and Google Places address autocomplete. The decision is not "should we have nice admin forms" — it is "do we spend engineering days hand-rolling Vue field components against a closed-source front-end contract, or do we configure existing ones?" For internal CRUD screens, configure. Admin UX is not a differentiator.

• Scope reduction on ops roadmaps. Specs that read "editors need to pick a date range," "finance needs money displayed and entered with a currency symbol," "we need an address field with autocomplete" convert from sprint-sized engineering work into configuration items measured in hours. That delta — roughly a week of component work per field type, times five or six fields — is the entire business case, and it returns capacity to customer-facing surfaces.

• Prioritization discipline: keep admin polish off the critical path. Because a zero-cost bundle covers a wide slice of "make the internal form nicer," any roadmap item whose entire value is admin aesthetics should rank low. Use the package's existence as the forcing function in backlog grooming.

• Time-to-market for internal MVPs. A new product line that needs a working back office this week can ship one thin by composing community fields rather than blocking launch on bespoke admin components.

• Maintenance-burden accounting. One bundle beats tracking six or eight separate field packages through Nova major upgrades. Small, but a real line item in upgrade planning — and a reason to prefer this over assembling individual field packages even at slightly worse per-field quality.

• Vendor and ecosystem risk ownership. Nova is closed-source and commercially licensed, and every field package inherits its upgrade cadence. This package's release history (last release May 2024) is an input to the larger "stay on Nova or migrate the admin surface to something open like Filament?" call. That is a decision PMs should own and put a date on, not delegate indefinitely to engineering.

• Data-quality exposure is a product decision, not only a technical one. Several fields transform input on write — currency normalization to minor units, slug generation, country codes stored as codes rather than names. A misconfiguration there silently writes bad data with no exception thrown. Rollout sequencing and a before/after audit on sample records belong in the plan the PM signs off on.

• Roadmap scoping input, not a roadmap driver. This is an enabler. It should appear in plans as "reduces admin build cost," never as a line item with a user-facing outcome attached to it.

When to Consider This Package

Adopt when:

• You are already committed to Laravel Nova and paying for the license. The package is inert without Nova; it is not a general Laravel form library and has no value in a framework evaluation.
• You need several of its field types. A bundle only beats focused packages or hand-rolled components when you consume more than one or two. Pick one display-only field for a single low-traffic internal resource first, then widen — adoption is per-field, per-resource, and rollback is a one-line revert.
• Your Nova major is explicitly covered by the pinned release. Verify the require block of composer.json against your Nova version before anything else; this constraint is the single compatibility gate. Note also that the marketed feature list and the actual source have drifted — enumerate field classes from src/, not the README, then subtract whatever Nova core now covers natively.
• The admin surface is internal-only, low blast radius, and free of accessibility, i18n, or compliance obligations you cannot otherwise meet.
• You can read and patch the source (MIT, effectively single-maintainer, zero listed dependents). The realistic posture is "we own the fork." That has to be acceptable before adoption, and you need a named internal owner who can patch a Nova field.
• You will wrap rather than scatter — declare fields through thin local factory classes and keep domain logic in fillUsing/resolveUsing on your own resources, so a future swap or upstream break is a one-file fix.

Look elsewhere when:

• You need an SLA, a security response process, or a reviewed security posture — go commercial or first-party.
• You are not on Nova, or are still evaluating admin frameworks. Do not let a field bundle anchor a framework decision.
• You need one field type only. Broad dependencies for narrow need is poor dependency hygiene.
• You require design-system conformance or deep accessibility. Community Nova field components rarely meet internal standards, and there is no upstream pressure to fix that.
• Your upgrade cadence is aggressive and you cannot absorb lag between Nova releases and this package's releases. A field package that goes a full Nova major without a release is a blocker, not a nuisance.
• The fields touch sensitive data flows. The Google Places field is the specific case — third-party API key, browser-originated outbound calls, quota and billing exposure, address data as PII. Treat it as its own decision, not a rider on the bundle, and keep it out of security review scope by default.

How to Pitch It (Stakeholders)

To executives: This is a free, MIT-licensed add-on for the Laravel Nova admin panel we already pay for. It supplies a library of ready-made form fields — currency, percentages, date ranges, rich text, country selectors, address autocomplete — so routine back-office work like internal screens, data entry, and content editing ships in hours rather than days, at no license cost and with zero customer-facing exposure. The trade-off is support: it is maintained by a small agency with a single maintainer, so we should assume we may need to patch it ourselves when Nova upgrades. That is an acceptable risk for internal-only software, it is cheap to reverse because it is confined to admin screens, and it does not touch revenue or customer data paths. Recommendation: adopt narrowly, pin the version, assign an internal owner, and re-evaluate at each Nova major upgrade.

To engineering: Adopt as a convenience layer on Nova, not a foundation. Four conditions. (1) Pin an exact version — field packages are coupled to Nova's front-end contract, not a public API, so a floating constraint is a production risk on every composer update. (2) Verify the Nova major against the package's composer.json constraint and put "re-validate nova-fields against the new Nova major" as a named line item in the upgrade runbook. (3) Wrap, don't extend — thin local field classes under app/Nova/Fields and domain logic in fillUsing/resolveUsing, so replacing a field or absorbing an upstream break is bounded to one file. (4) Roll out per field, per resource, starting with one display-only field on one low-traffic resource; success means it renders cleanly on form, detail, and index, the console is clean, and the value round-trips unchanged. Treat the write-transforming fields (currency, slug, country) as data-quality events requiring a before/after audit before wider rollout, keep Google Places behind its own go/no-go with a referrer-restricted key, and assume the default posture is that we own the fork.