Filament Js Money Field Laravel Package

Product Decisions This Supports

• Feature delivery for money-entry surfaces. Any Filament admin panel feature that captures a monetary amount — invoice line items, refunds, payouts, plan pricing, expense entry, marketplace commissions — can use this field instead of a plain numeric input. This is the primary decision it unblocks: "can we ship the finance CRUD screens this sprint without a custom input component?"
• Build vs. buy (buy, at small scale). The scope is narrow: a Filament form field wrapping js-money for currency-aware formatting and minor-unit handling. Building equivalent behaviour in-house is roughly 1–3 days of engineering plus ongoing ownership of client-side formatting edge cases. Adoption is the cheaper call unless you already have a house money-input standard.
• Standardisation decision. Whether to make this the default currency field across your Filament resources, or permit it only in specific panels. A v0.x, single-maintainer dependency is usually fine as a leaf-node UI component and less fine as a mandated org-wide standard.
• Data-integrity risk reduction. Money entered as free text into decimal columns is a recurring source of rounding and locale bugs (comma vs. decimal separator, 2- vs. 3-decimal currencies). Choosing a currency-aware field is a product-quality decision, not just a UI one.
• Roadmap sequencing. Because the field is swappable and low-blast-radius, it can land ahead of related work (multi-currency pricing, tax engines, payment provider integration) without creating lock-in. It does not substitute for those; do not let it stand in for a server-side money value object.
• Release signal (v0.1.7). A null-model guard in getColumnType — the failure mode is a crash when the form is rendered without a bound Eloquent record, i.e. on create pages. If you have create forms using this field, this patch is a genuine stability fix worth taking. No breaking changes, no new features, no deprecations; it does not change the adoption calculus.

When to Consider This Package

Consider it when:

• You are already on Filament and need currency-aware amount inputs inside resources, relation managers, or custom admin forms.
• Your amounts map cleanly to ISO 4217 codes with a known minor-unit exponent, and client-side formatting matching js-money semantics is acceptable.
• You want the cheapest path to a decent money input and are comfortable pinning an exact version (0.1.7) in composer.json.
• The field is a leaf dependency — a UI widget whose removal would be a contained refactor rather than a schema or API change.
• You can absorb single-maintainer risk, or you are willing to wrap it in your own field class so you can swap or fork it later.

Look elsewhere when:

• You need server-side money semantics: immutable value objects, arithmetic, allocation, rounding policies. Use moneyphp/money or brick/money for the domain layer and keep this strictly as the input surface.
• You need multi-currency conversion, FX rates, or per-store currency resolution — that is application logic, not a field.
• You need storefront or customer-facing checkout UI; this is an admin-panel component.
• You have regulatory or audit requirements demanding validated, server-authoritative decimal handling with a tested rounding policy. A client-side-formatted input is not a control.
• Your organisation bars pre-1.0 or single-maintainer dependencies without a fork/vendor plan.
• You are not on Filament, or are on a version this package does not track.

How to Pitch It (Stakeholders)

For executives. This is a small, low-cost component that lets us ship money-entry screens in our admin tooling faster and with fewer data-entry errors. It handles currency formatting so operators see and enter amounts correctly, rather than us rebuilding that logic per screen. The exposure is deliberately limited: it is a single form field, it is pinned to an exact version, and replacing it would be a contained piece of work rather than a platform change. The latest patch (v0.1.7) fixes a crash when the form is used on creation screens — a straightforward reliability improvement with no breaking changes and nothing for us to re-plan.

For engineering. Thin Filament field over js-money; the surface is one field class plus a view. v0.1.7 adds a null guard in getColumnType so unbound-model (create) forms no longer error — a one-line class of fix from a first-time contributor, so review the diff before bumping. No API changes, no deprecations, no migration work. Recommended handling: pin 0.1.7, wrap the field in our own subclass so call sites are insulated from upstream churn, add a feature test covering the create-page path that this release fixes, and keep the domain-side amount representation in a proper money value object — this package is the input widget, not the source of truth for monetary values.