Nova Money Field Laravel Package

Product Decisions This Supports

Feature-level: money input in the admin panel. Any workflow where an operator types or reads a monetary amount — product pricing, invoice line items, plan tiers, refunds, payouts, shipping thresholds — is where this field earns its place. It replaces a generic Number field with one that is currency-aware, which is the difference between "1999" and "$19.99 USD" being unambiguous to the person entering it and to the system storing it.

Build vs. buy: buy (or fork), not build. A currency-aware Nova field is a small, well-bounded piece of UI plus a formatting/parsing layer. Writing it in-house costs a few days of engineering plus permanent maintenance on a low-glamour surface. Adopting a package — or vendoring its ~few-hundred lines into app/Nova/Fields — is the better trade unless you have unusual requirements (custom rounding rules, tax-inclusive display, FX conversion).

Roadmap: international expansion. The moment pricing or billing goes multi-currency, every admin screen that touches an amount becomes a correctness risk. A field that carries currency alongside the amount lets you ship multi-currency pricing without a parallel admin redesign, and without a data migration later when you discover amounts were stored as bare integers with an implicit currency assumption.

Roadmap: finance/ops self-service. Ops teams filing tickets to "fix a price" is a lagging indicator of a bad admin UI. A properly formatted, validated money input reduces mis-keyed amounts and the reconciliation work that follows them — a cheap reduction in a category of support load that is otherwise invisible until it's expensive.

Data-model decisions. This field presumes (or nudges you toward) storing money as integer minor units plus a currency code, rather than floats or bare decimals. That is the correct default and worth adopting explicitly as a team convention; the field is a forcing function for it.

Use cases that fit: e-commerce catalogs, subscription plan management, invoicing/back-office tooling, marketplace payouts, any Nova-backed internal ops tool where humans touch prices. Use cases that do not: customer-facing checkout logic (this is an admin field, not a pricing engine), FX conversion, or accounting-grade ledgers requiring arbitrary-precision decimals and rounding policies.

When to Consider This Package

Adopt when all of the following hold:

• You are on Laravel Nova and intend to stay there. This package has no value outside Nova — it is not a general Laravel cast, validation rule, or Blade component.
• Your amounts are (or will be) multi-currency, or you have a single currency but want the formatting and validation discipline baked in.
• You store money as integer minor units plus a currency code, or are willing to migrate to that.
• You can absorb the dependency: confirm the supported Nova major version (Nova 4 vs. 5 are meaningfully different APIs), the PHP version floor, and which money library it wraps (moneyphp/money and brick/money are the common choices and are not interchangeable).

Treat the maturity signals seriously. Zero stars, zero dependents, no score means: no community validation, no evidence of production use, and no implicit bug-finding. That does not make it bad — small single-purpose fields are often correct and unmaintained simply because they are finished — but it does change how you adopt it. The right posture is vendor it: read the source (it is small), copy it into your codebase as a Nova custom field, and own it. That removes the abandonment risk entirely, and the cost is a day of a mid-level engineer's time.

Look elsewhere or build when:

• You are single-currency and will plausibly stay that way for two years — Nova's built-in Number field plus a currency label is adequate and free.
• You need FX conversion, tax-inclusive/exclusive display toggles, or locale-specific rounding. This field formats; it does not do pricing logic, and stretching it there will be worse than building the small thing you actually need.
• Your Nova version isn't confirmed supported, or you're on a Nova release the package predates.
• You need a maintained dependency with a security-response path. Nobody is answering advisories on a zero-star repo.

Also verify before committing: how it serializes to the model (does it hand you minor units or a decimal string?), whether it validates on the server side or only masks on the client, and how it renders on the index/detail views versus the form. Those three answers determine whether it's a drop-in or a starting point.

How to Pitch It (Stakeholders)

To executives (one paragraph): We have a recurring class of error where prices get entered into the admin panel incorrectly, and it gets more expensive as we add currencies. This is a small, free, open-source component that makes money inputs currency-aware and self-validating in our admin tool. The engineering cost is under a day; the payoff is fewer reconciliation incidents and no rework when we expand beyond one currency. It is small enough that we can own a copy outright, so we carry no dependency or vendor risk.

To engineering (the real pitch): It's a Nova field that wraps a money value object so the admin form speaks in currency + amount instead of a bare number. It enforces the minor-units-plus-currency convention we want anyway. Caveats: unmaintained, no dependents, so we vendor it into app/Nova/Fields rather than pulling it from Packagist — read the source first, confirm it targets our Nova major and money library, and check that server-side validation exists rather than only input masking. If it's thin on validation, we add a Money cast and a form request rule and keep the field purely presentational.

To the team, the decision in one line: Adopt as a vendored reference implementation behind a one-day spike, not as a critical-path dependency; revisit if multi-currency slips off the roadmap, in which case drop it for a plain number field.