Nova Money Field Laravel Package

Technical Evaluation

Architecture fit. A Nova field is a thin package: a PHP Field subclass plus a compiled Vue component registered through a service provider. It sits at the presentation edge of the stack, so architectural coupling is minimal — it does not touch models, migrations, or domain logic. The only real architectural question is whether the field treats money as a display concern (good) or tries to own persistence/formatting semantics (risky). For a money field the correct design is: store integer minor units + ISO currency code in the database, and let the Nova field only serialise/format for the UI.

Integration feasibility. Mechanically trivial — composer require everestmx/nova-money-field, register in a Nova::resources() field list, publish assets if required. Blockers are almost always version constraints: confirm the composer.json requires block for laravel/nova (3.x vs 4.x vs 5.x), laravel/framework, and PHP. Nova packages that hard-pin laravel/nova to an old major become uninstallable the moment you upgrade Nova.

Technical risk. This is the dominant concern. With zero stars and zero dependents there is effectively no community validation, no security disclosure path, and no evidence of maintenance. Money is a high-blast-radius domain: float-based arithmetic, rounding mode, thousand-separator parsing on input, and currency mismatch are all silent-failure classes that surface as accounting discrepancies, not exceptions. Additional unknowns: test coverage (likely none), whether the Vue component is pre-built or requires a local npm build, and whether it was ever validated against a Nova release you actually run.

Also note the low lock-in upside: because field configuration lives in PHP resource classes rather than the database, swapping this package for an alternative later is a one-line change per resource. That materially reduces the cost of being wrong — which is the only reason this is even worth a spike.

Key questions to answer before a decision:

• Which Nova/Laravel/PHP versions are declared, and are the constraints ^-ranged or hard-pinned?
• Does it store and emit integer minor units, or floats/strings? Is there an explicit currency per field, per record, or global?
• Does it support form, index, detail, and inline-create views? Sorting and filtering on index?
• Are assets shipped pre-compiled, and is there a nova:publish/Vite path?
• Any tests, CI, release history, or maintainer activity in the last 12 months?
• How does it behave with locale-specific separators (1.234,56) and paste-in input?

Integration Approach

Stack fit. Assumes a Laravel + Nova monolith or admin surface. It fits cleanly if you already have — or are willing to introduce — a canonical money representation (integer minor units + currency) in your domain layer. If your models currently store DECIMAL(10,2), decide the canonical format first; the field must render that, not define it.

Migration path. Do not rip out an existing Number field or Blade-formatted display wholesale. Instead: (1) spike the package in a branch against a throwaway resource; (2) confirm rendering across form/index/detail; (3) if it holds, vendor-fork it into a private repo pinned to a commit SHA; (4) roll out to one low-traffic resource; (5) expand. If it fails the spike, fall back to vyuldashev/nova-money-field (established, maintained) or a ~100–150 line in-house field — a Nova money field is genuinely small to build and gives you test coverage you control.

Compatibility. Verify against your exact Nova major before committing. Watch for asset-manifest breakage on Nova upgrades and for Composer resolution conflicts if another package pins a different Nova range. Prefer a pinned fork over dev-main so an upstream force-push cannot silently change what you ship.

Sequencing. Version-compatibility check → throwaway spike → rounding/locale correctness tests → in-house fallback decision → one-resource pilot → wider rollout. Budget 1–2 days for the spike and fallback evaluation; do not let this sit on the critical path of a Nova upgrade.

Operational Impact

Maintenance. Assume it is unmaintained. You should expect to own it: pin to a commit, fork on first needed fix, and budget a small recurring cost (roughly 1–2 days/year) for Nova upgrade compatibility. Treat any upstream commit as untrusted until reviewed.

Support. No SLA, no issue triage guarantees, no security advisory channel. Internal ownership must be explicitly assigned — otherwise a broken money field becomes an orphaned dependency discovered during an incident.

Scaling. Runtime cost is negligible: one Vue component per field instance, no server-side queries beyond the resource's normal select. Index pages with several money columns are fine. The real "scaling" risk is organisational: more resources adopting the field multiplies the blast radius of a formatting bug.

Failure modes to instrument/guard:

• Silent float rounding drift between stored and displayed values.
• Currency mismatch (field default vs record currency) producing plausible-but-wrong figures.
• Nova upgrade breaking asset compilation → field renders blank or throws in the browser console.
• Locale separator parsing corrupting input on save.
• Missing/never-run migrations if the field assumes a column shape it doesn't enforce.

Ramp-up. Low for any developer with Nova experience — hours, not days. The non-obvious cost is domain literacy: developers must understand minor-unit storage, rounding policy, and currency handling to use the field safely. Pair the rollout with a short written convention (storage format, currency source of truth, rounding rule) so the field stays a view concern rather than becoming a de facto money API.

Recommendation. Do not adopt on the strength of this package alone — zero adoption is a disqualifier for a correctness-critical concern like money. Run the spike only because switching costs are low; default to an established alternative or a small in-house field with tests you control.