Nova Fields Laravel Package

Product Decisions This Supports

• Build vs. buy vs. fork for admin-panel UX. Nova is already a paid, licensed dependency, so every additional field package is a marginal buy decision. At MIT license, one field's scope, 7 stars, zero dependents, and a last release of May 2022, this is source material, not a runtime dependency. The real line item isn't license or integration effort — it's permanent internal ownership. Reframe the request from "add a package" to "budget roughly a day of engineering to vendor and own one field type."
• Whether a bespoke field is needed at all. The most valuable output of this evaluation is a forced inventory: which admin screens genuinely need a custom input, and which are already served by Nova's built-ins plus relationship fields and formatting configuration. Most "we need a custom field" tickets collapse at this step — a roadmap win at zero cost and zero maintenance.
• Prioritization of internal tooling. Admin panels are internal-facing and rarely customer-visible. A low opportunity score (27/100) is the signal to keep custom-field work in the low-priority lane unless it unblocks a revenue-critical workflow: support triage, billing ops, moderation, or compliance review.
• Maintenance-burden forecasting. Single maintainer, no dependents, no CI, no CVE path, two years stale. This is a concrete data point for the standing question "how much of our admin surface are we self-supporting?" Every low-adoption Nova package adopted implicitly transfers its maintenance to us — and that shows up as engineering capacity in a future quarter, not this one.
• Compatibility gating for Nova upgrades. Any use forces three explicit checks before code lands: Nova major version (3 vs 4 vs 5), the package's PHP/Laravel constraints, and frontend tooling (Vue 2 FormField mixin vs Vue 3 component API). That gating exercise is itself a roadmap input for scheduling the next Nova upgrade and deciding how much admin surface we're willing to re-port.
• Risk posture on security-adjacent surfaces. Anything touching money, PII, permissions, or an audit path should not inherit an unmaintained, unaudited field component. Use this package as the precedent for how we triage "small abandoned dependency" requests generally: pin the risk, name the owner, or decline.

When to Consider This Package

Consider it when:

• You are genuinely on the Nova major this package targets — verify against the May 2022 release date before anything else — and one of its field types maps exactly to a gap you've already confirmed the built-ins can't fill.
• You want a reference implementation for authoring your own Nova field. Reading a small working example of make(), rules(), withMeta(), resolveUsing(), fillUsing(), and a FormField-based Vue component is cheaper than reading Nova's authoring docs cold, and MIT means you can copy the patterns freely. In practice this is the highest-value outcome.
• You're running a timeboxed spike or internal prototype where a vendored, throwaway admin screen is acceptable and no production data is at stake.
• You have a named engineer who will own the forked code and a place to keep it — in-repo under app/Nova/Fields, never in vendor/ — plus a README and an upgrade-checklist entry written at fork time.

Look elsewhere when:

• You're on Nova 5 or a current Laravel/PHP release. A package last shipped in May 2022 has almost certainly not been tested against it; assume incompatibility until proven otherwise by a composer require --dry-run.
• The field touches money, PII, permissions, or anything on a security review path. Zero dependents and no visible audit or CI means nobody has stress-tested nulls, empty arrays, repeat saves, or whether the Vue component escapes user HTML before round-tripping it to the database.
• You need support, an SLA, or a CVE response path. There is no upstream capacity to rely on and no issue to file against.
• A built-in Nova field, an official Laravel package, or a higher-adoption community package covers the same need. Switching cost is trivial at this scale, so adoption count is a cheap and reliable tiebreaker.
• The documentation is effectively the package description ("A Laravel Nova field"). That is a real evaluation cost — budget time to read the source before committing, and walk away if the source isn't clean.

Decision rule to carry forward: adopt as a dependency only if the app is genuinely on Nova 3 and the need is non-critical; otherwise fork the relevant class into owned code, or use it purely as a reference and write your own field against your own data contract.

How to Pitch It (Stakeholders)

For executives: This is a small, MIT-licensed UI component for our Laravel Nova admin panel — not a platform bet. It carries no license cost and no vendor lock-in, but it is two years stale, has essentially no user base, and has no maintainer to call if it breaks. The decision on the table is therefore not "buy software," it's "do we want to own one field type permanently." Recommendation: do not adopt it as a dependency; either use it as a free reference implementation to write our own field in under a day, or skip it entirely if Nova's built-ins cover the need. Expected cost is one engineer-day; the alternative cost is an unowned, unaudited component sitting inside our admin surface indefinitely.

For engineering: Treat the source as documentation. Clone it, read composer.json for Nova/Laravel/PHP constraints, read the field class and the .vue component, and answer three questions: what $component string does it register, what does it write to the model, and does a prebuilt dist/ exist. Expect Composer resolution to fail on Nova 4/5 — that's the normal case, not a mid-sprint surprise, and the answer is to vendor the class into app/Nova/Fields rather than fight it with --ignore-platform-reqs. If we do any of this: one low-risk resource, explicit rules() and nullable() on every usage, onlyOnForms() unless index/detail views are actually implemented, normalization done at the field boundary via resolveUsing()/fillUsing() rather than in the component, and two tests — a jsonSerialize() shape assertion plus a feature test hitting the Nova update endpoint and asserting the DB value. The UI is not the test; silent mis-serialization is the dominant failure mode. Keep the forked component surface as small as possible, because every line changed there is a line we re-port at the next Nova major.

Bottom line: Low priority, low risk, low ceiling. Fund it only as a reference read or a one-day vendored fork with a named owner — and use the evaluation itself to close out the "do we actually need a custom field?" question first.