Filament Money Field Laravel Package

Technical Evaluation

Architecture fit: pelmered/filament-money-field is a single-purpose Filament form component that wraps money/currency input handling (amount + currency pair, formatting, casting). It is a leaf-level UI dependency — it sits on top of Filament's form field API and, transitively, Livewire. It does not own domain logic, persistence, or money math beyond the presentation layer, so it should not become a system of record for monetary values. Treat it as a view-layer convenience, with the underlying value object (e.g. moneyphp/money or a bespoke cast) remaining the authoritative representation.

Integration feasibility: Straightforward for teams already on Filament. Composer require plus registering the field in a form schema is the whole integration surface. The 2.0 line is a ground-up rewrite (PR #81) rather than an incremental bump, meaning the field's constructor signature, configuration methods, and state/ dehydration behavior may differ from 1.x. Feasibility is high, but only after a spike against our actual form schemas — not from the README alone.

Technical risk: Elevated for three reasons. First, beta status: 2.0.0-beta.4 is the fourth beta of a major rewrite; API surface can still move between betas, and there is no stated GA date. Second, framework coupling: the release simultaneously adds Filament v4 support and permits Filament v5 installation. A single 2.0 line spanning v3/v4/v5 compatibility is a maintenance burden the package author is absorbing, and it is the most likely source of field-level breakage on our side if we upgrade Filament independently. Third, currency mutation bugs: PR #108 fixes an error when changing currency in Filament v4 — a core interaction path. That such a defect shipped in the v4 support work is a signal that the v4/v5 compatibility matrix is under-tested relative to the number of combinations now claimed. Money handling is a domain where "renders but stores the wrong minor unit" is a silent, expensive failure, so we should verify persistence and casting ourselves rather than trusting the field's dehydration.

Key questions:

• What is the maintainer's GA timeline and backward-compatibility commitment for 2.0?
• Which Filament versions does our application actually pin, and does our Livewire version match what the v5-permissive constraint pulls in?
• Does the field's dehydration path produce integer minor units, a decimal string, or a float — and does that match our existing casts?
• Is there a documented 1.x → 2.0 migration guide, or must we diff the source?
• What is the test coverage across the v3/v4/v5 matrix, and is CI running all three?
• Who is the bus factor here? The release adds three first-time contributors, which is healthy for velocity but also means recent code paths have had limited review history.

Integration Approach

Stack fit: Good, if and only if we are standardising on Filament for admin/back-office surfaces. The package is opinionated toward Filament's form lifecycle; any non-Filament surface (public-facing checkout, API resources, imports) gets no benefit and should use a plain money cast instead. Scope the dependency to the Filament panel, ideally as a require-dev-adjacent or panel-scoped concern rather than a transitive dependency of our domain layer.

Migration path: From 1.x this is a major version — assume breaking changes to field configuration and state handling until proven otherwise. The safe path is: (1) build one production-equivalent form on 2.0-beta.4 in a branch, (2) exercise currency switching, locale changes, zero/negative amounts, and very large amounts, (3) confirm round-trip persistence to the database matches expectations, (4) then migrate forms one at a time. Do not attempt a wholesale bump. If we are not yet on Filament v4, hold — this release's headline value is v4 support, so adopting the beta while remaining on v3 buys risk without benefit.

Compatibility: The release explicitly widens the install constraint to permit Filament v5. That is permissive rather than validated. Pin Filament in our own composer.json and let the package resolve against it; do not allow the package to drive our Filament version. Also verify PHP and Livewire constraints, since Filament major bumps typically move both.

Sequencing:

1. Spike branch: install beta.4, port a single representative form, document any API deltas from our current version.
2. Validate persistence semantics (minor units, casting, nullability) against our existing schema and casts.
3. Confirm our Filament version pin is stable and our Livewire/PHP versions satisfy the field's requirements.
4. Regression-test the currency-switch path specifically — this is the path that was broken and fixed within the beta series.
5. Roll out form-by-form behind the existing schedule; keep 1.x pinned on any panel we are not actively migrating.
6. Re-evaluate at GA before declaring the migration complete.

Operational Impact

Maintenance: Low ongoing code cost, but non-trivial version-tracking cost. We inherit a dependency whose upstream is actively absorbing three Filament major versions at once; expect frequent patch releases and occasional beta churn. Budget a small recurring allowance for version bumps rather than treating this as install-and-forget. Track the repo's release cadence and GA signal as an explicit line item.

Support: Upstream support is community-driven via GitHub issues on a small project. There is no vendor SLA. First-time contributors landing compatibility work is a positive signal for the project's health but a caution for the review depth of the newest code. We should not plan to escalate production incidents to the maintainer; our own engineers must be able to read this package's source, which is feasible given its size — a few hundred lines of field logic at most.

Scaling: Negligible runtime scaling concern. The field is form-level UI; cost is bounded by the number of rendered fields per page. The real scaling axis is organisational: every additional Filament panel and every future Filament upgrade becomes a compatibility checkpoint. If we end up with many panels, centralise the field configuration in a shared base class so an upstream breaking change is a single-point fix.

Failure modes: The dangerous failure is silent, not loud. A currency-switch or dehydration regression stores a wrong amount or a wrong minor-unit scale, which surfaces days later in reconciliation, not in a stack trace. Secondary failure: a permissive Filament v5 constraint resolves a version we have not tested, producing runtime schema errors in the admin panel. Tertiary: a beta-to-beta API change breaks a form at deploy time — loud and cheap by comparison. Mitigations: assert monetary values in feature tests that hit the real database, pin Filament explicitly, and avoid floating-point or string-typed money columns in favour of integer minor units.

Ramp-up: Minimal for any engineer who already knows Filament forms — the field is a drop-in with a small configuration surface, on the order of an hour to first productive use. The ramp-up that matters is not the API but the semantics: engineers must understand how the field dehydrates state and where the authoritative money representation lives. That is a 30-minute design conversation and a code review rule ("money never originates in the form layer"), and it is worth having before the first form merges rather than after.