Nova Money Field Laravel Package

Product Decisions This Supports

• Build vs. buy for back-office money input: if you run Laravel Nova for internal admin/ops tooling, this package replaces a hand-rolled currency field and its associated validation, formatting, and storage conventions. At roughly a one-file field plus a Money cast, "buy" is defensible purely on avoided maintenance, but the decision is low-stakes either way — treat it as a small, reversible bet.
• Multi-currency roadmap: the field is a thin Nova adapter over moneyphp/money, so adopting it signals (and cheaply tests) a commitment to integer-minor-unit storage plus an explicit currency code, rather than float or single-currency columns. That is a schema decision, not just a UI one, and it is much cheaper to make before you have pricing data in production than after.
• Financial correctness in internal tools: support/sales/ops staff editing prices, refunds, or credits by hand is a recurring source of rounding and locale bugs. A currency-aware field narrows that class of defect without an engineering project.
• Dependency lifecycle planning: v1.5.0's only substantive change is adding moneyphp/money v4 support. This unblocks teams whose other dependencies (or PHP 8.x baseline) already push them onto money v4, and it de-risks the upgrade path for teams still on v3 — relevant if you maintain a shared internal package set and want a single money library version across services.
• Not a customer-facing decision: this has no bearing on end-user product surface. Budget it as tooling hygiene, not roadmap capacity.

When to Consider This Package

Consider it when all of the following hold:

• You use Laravel Nova (a commercial license is already a prerequisite — this package is worthless without it).
• You store monetary amounts as moneyphp/money objects or intend to, and you need Nova forms to round-trip them without lossy float conversion.
• You need genuinely multi-currency input, or you need locale-correct formatting for operators — a single-currency, single-locale admin can be served by a plain Number field with a mask.
• Your PHP/Nova versions sit inside the package's supported matrix, and your moneyphp/money constraint matches what v1.5.0 actually declares. Verify this directly: the release note is one line plus a changelog link, and it does not state whether v4 support was added alongside v3 or replaced it. If v3 was dropped, this is a breaking change for anyone on older PHP, and you should pin accordingly before upgrading.

Look elsewhere or skip it when:

• You are not on Nova, or you are evaluating a move off Nova — a Nova-specific field is a small but real lock-in that will be thrown away in a migration.
• You need the field outside Nova (Livewire, Filament, API resources): use moneyphp/money directly with a custom cast and form request validation; the library is the substance, this package is the veneer.
• Maintenance concentration is a concern. This is a small, single-maintainer package with low release cadence and thin release notes. For anything touching revenue-critical input paths, plan to vendor it or fork it — the code surface is small enough that a fork is hours, not weeks, which is also what makes the dependency acceptable in the first place.
• Your money handling needs are broader than a form field (currency conversion, tax, proration). This package does none of that; don't let it stand in for a pricing service decision.

How to Pitch It (Stakeholders)

For executives: This is a small, low-cost dependency that reduces a known category of back-office error — staff manually entering prices and refunds into the wrong currency or with rounding mistakes. The new release is a maintenance update that keeps it current with the underlying money library; no new features, no user-visible change, no migration work for us if we adopt it now. Cost is effectively zero beyond the Nova license we already hold, and the exit cost is low because the package is thin.

For engineering: v1.5.0 adds moneyphp/money v4 compatibility — the practical effect is that we can standardise on money v4 across the codebase instead of holding a v3 island for the admin field. It is a compatibility release, not an API change, so there is no rework on our side. Two caveats worth 30 minutes of diligence before we commit: confirm whether the v4 constraint is additive or a replacement (i.e. whether v3 is still supported), and confirm Nova version coverage against our install. Given the maintainer risk, if we adopt, vendor the field into our repo — it's small, and that removes the single-maintainer concern entirely while keeping the upgrade we just got.