Filament Money Laravel Package

Technical Evaluation

Architecture fit. ymsoft/filament-money is a narrow, single-concern plugin that sits in the presentation/storage boundary of a Filament admin panel: it supplies a form field (masked decimal input, currency selector, locale-aware formatting) plus a cast or accessor/mutator pair that translates between the database column and a money value object. That is the correct shape for this problem — money handling in Filament is a known rough edge, because Filament's stock TextInput and TextColumn treat values as floats or raw strings, and naive ->numeric() fields leak binary floating-point error into financial data. As a TPM I would position this package as a thin convenience layer, not an accounting engine: it should not be relied upon for tax calculation, FX conversion, or ledger postings.

Architecturally the important question is what it delegates to. If it depends on moneyphp/money or brick/money, we inherit a battle-tested value object with correct minor-unit arithmetic and ISO 4217 currency metadata, and the plugin is genuinely low-risk glue. If it rolls its own value object or — worst case — performs arithmetic on floats internally, the plugin becomes a liability hiding behind a nice UI. The repository metadata does not answer this, and it is the first thing to verify in code review.

Integration feasibility. Composer-installable, Laravel package auto-discovery, MIT licensed — no procurement or legal friction. Integration is expected to be three lines: composer require, register the plugin on the Panel in the PanelProvider, and swap TextInput/TextColumn for the package's field classes. A php artisan vendor:publish step for config (default currency, locale, symbol placement, decimal separator) is likely. Realistically a competent Laravel developer completes a spike in half a day.

The non-trivial work is not the package — it is our schema. If the plugin assumes integer minor units stored in a BIGINT column, that is the correct design but may not match existing DECIMAL(10,2) columns; if it assumes DECIMAL, it is simpler to adopt but constrains us to two-decimal currencies and complicates future FX. Either way, adoption triggers a data-shape decision, backfill, and a validation pass against production data.

Technical risk. The dominant risk is not technical, it is provenance. Ten stars, zero dependents, and a single-author GitHub account means effectively zero production validation and a bus factor of one. A recent release date is reassuring for activity but tells us nothing about correctness under load or across currency edge cases. Specific technical risks to close out before committing:

• Version-matrix compatibility: Filament v3 vs v4, Livewire v3, PHP 8.2/8.3, Laravel 10/11/12. Filament major versions churn form-field APIs aggressively, and an unmaintained plugin will hard-block a panel upgrade.
• Currency edge cases: zero-decimal currencies (JPY, KRW), three-decimal currencies (KWD, BHD), and the ISO minor-unit lookup that must drive them.
• Sorting and filtering: TextColumn money formatting is display-only; verifying that sorting still hits the underlying numeric column rather than a formatted alias is essential for admin usability at scale.
• Livewire round-tripping of value objects through hydration, and behaviour on null/zero/negative values.
• Rounding policy on mutation — half-up vs banker's rounding — and whether the cast is lossless on repeated read/write cycles.

Key questions for the maintainer or code review: Which money library, if any, is the arithmetic dependency? What is the declared support matrix across Filament, Livewire, Laravel, and PHP? What is the storage contract (minor units vs decimal, column type, currency column location)? Is multi-currency supported, and is there any FX or conversion surface (there should not be)? What is the test suite coverage on currency edge cases, and is there CI? What is the deprecation/BC policy?

Integration Approach

Stack fit. Excellent, if we are already on Filament. It is a same-vendor, same-ecosystem package with no new runtime dependency beyond the underlying money library and no new infrastructure. For a Laravel/TALL-stack product this is the lowest-friction category of dependency: no service, no container, no external call. It fits cleanly into the existing App\Filament\Resources layer without touching domain or persistence code, provided we keep monetary rules (pricing, tax, discounting) in our own domain services and use the package only for input, cast, and display.

Migration path. Sequence it as a bounded pilot rather than a horizontal rollout:

1. Spike in a throwaway branch. Install, exercise the field against a scratch resource with a deliberately awkward dataset (JPY, KWD, negative amounts, large values, nulls). Confirm what the cast writes to the column.
2. Pin and lock. Exact-version pin in composer.json with a documented upgrade owner; capture the resolved version in the ADR.
3. Decide the storage contract against existing schema. If current columns are DECIMAL(10,2) and the package wants minor units, do not convert in place. Add parallel columns, dual-write, verify parity with a reconciliation query, then cut over and drop the old columns in a separate release.
4. Wrap it. Introduce our own MoneyCast and MoneyInput aliases (or a thin App\Support\Money facade) so resources reference our classes, not Ymsoft\... directly. This is the single highest-value step: it converts a bus-factor-one dependency into a swappable implementation detail.
5. Pilot on one low-blast-radius resource (e.g. a supplier price list or product cost field) for one release cycle with real users.
6. Expand resource by resource, gated on the pilot producing no data-integrity incidents.

Compatibility. Treat the Filament major version as the hard gate. If our panel is on Filament v3 and the package only declares v4 (or vice versa), stop — do not patch around it, because the next Filament upgrade will break the workaround silently. Also confirm Laravel and PHP constraints against our platform baseline before the spike, not after.

Sequencing note. Do the schema decision before the UI swap. Reversing that order means writing money fields against a column shape we intend to abandon, and reworking the resource twice.

Operational Impact

Maintenance. This is the weakest dimension. One maintainer, ten stars, no dependents, no visible commercial backing. We should assume we may need to fork within twelve months. That is acceptable only because the surface area is small — a field, a cast, and formatting config are a few hundred lines and comfortably forkable — and because the wrapper layer in step 4 means a fork is a namespace change rather than a resource rewrite. Budget a modest, explicit maintenance allowance: an owner, a quarterly review of upstream releases, and a standing item on the Filament upgrade checklist.

Support. Community-only, via GitHub issues on a low-traffic repository. Expect slow response, no SLA, and no security advisory process. Mitigation: our own smoke tests around the field so regressions surface in CI rather than in production. Note also that a currency-formatting plugin has a shallow attack surface — no deserialization of untrusted payloads, no network calls — so the security exposure is low even without an advisory channel.

Scaling. Negligible runtime cost: formatting and casting are pure in-process string/number operations with no measurable per-request overhead. The scaling risks are functional, not volumetric. First, formatting-heavy TextColumns on large tables: confirm sorting and searching resolve to the underlying numeric column, or admin list performance degrades and sort order becomes lexicographic. Second, aggregation queries (revenue rollups, reporting) must continue to run against the raw column — never against formatted output — so our reporting layer must stay unaware of the plugin. Neither is blocking at typical admin-panel volumes.

Failure modes. Ranked by expected damage:

• Silent precision loss from float arithmetic or lossy casting on write — the worst outcome, because it corrupts financial records without throwing. Guard with reconciliation queries and a DB-level check on the column type.
• Currency mismatch: display currency drifting from the currency actually stored on the row. Guard by storing the currency code as an explicit column, not deriving it from config.
• Rounding drift on high-volume repeated edits, if the cast is not idempotent.
• Upgrade breakage on Filament or Livewire majors — visible and loud, therefore the least dangerous of the set, provided we have the wrapper.
• Abandonment: the package stops receiving releases and eventually blocks a platform upgrade. Slow-burn, fully mitigated by the wrapper and fork plan.
• Locale/formatting regressions (separator conventions, symbol placement) — cosmetic, user-visible, low damage.

Ramp-up. Low, for anyone already productive in Filament: the API is idiomatic and a developer unfamiliar with the package should be shipping a money field within an hour. The real ramp-up cost is conceptual, not syntactic — engineers must internalise the minor-units storage contract and the rule that no arithmetic happens in the UI layer. Budget a short written standard ("all money is integer minor units plus an explicit ISO code; no floats in the domain; formatting is display-only") alongside the pilot. That document, not the package, is what prevents the precision failures above.