Filament Brl Money Field Laravel Package

Technical Evaluation

Architecture fit. This is a leaf-level presentation concern: a single Filament form field that renders a BRL-masked input and hands state back to Livewire. It belongs strictly in the admin UI layer and should never be allowed to shape domain or persistence design. Architecturally it is interchangeable with a plain TextInput plus client-side masking, which sets the build-vs-buy bar low. Fit is good only if the product runs a Filament admin and serves pt_BR users; it adds nothing outside that surface.

Integration feasibility. Installation is a one-line composer require, and usage is a single class import inside a resource form. There is no service provider wiring, no migrations, and no config surface confirmed by the docs. That makes a spike cheap — an engineer can validate it in a branch in under a day. The real integration work is not the field itself but the surrounding decisions: how the masked string is normalized, what the database column type is, and whether the package already dehydrates to cents or a decimal string.

Technical risk. High relative to the value delivered. Concretely:

• Adoption signal is essentially zero (1 star, single maintainer). Bus factor is one, and there is no evidence of a maintenance cohort.
• Filament major-version coupling. Filament v3 and v4 field APIs diverge; a patch release will not widen constraints. The package is only safe if composer.json explicitly matches the app's Filament major.
• Masked-state ambiguity. The central hazard is that the form state, validation input, Livewire hydration payload, dehydrated value, and DB column may each see a different representation of 1.234,56. If the field already converts to cents, adding a dehydrateStateUsing multiplies by 100 twice.
• Undocumented extension points. Whether prefix/suffix, mask behavior, or locale parsing can be overridden via protected methods is unknown; subclassing a Filament field is brittle across minor releases.
• ext-intl/locale dependence. Formatting may rely on intl or app locale, so behavior can differ between local and production.
• Release hygiene. v1.0.1 ships with no changelog beyond a diff link; treat as bug-fix-only and review the diff before upgrading.

Key questions to resolve before committing.

1. Which Filament, Laravel, Livewire, and PHP versions does composer.json constrain, and does that match our app exactly?
2. Does the field dehydrate to integer cents, a decimal string, or the raw masked string? (Inspect src/ — do not trust the README.)
3. Does it depend on ext-intl, and is that extension guaranteed in production?
4. Are there configurable prefix/suffix/mask options, or protected methods, that avoid subclassing?
5. Does masked state survive Livewire re-render/hydration (->call('$refresh'), dependent-field updates)?
6. How does it handle 0, -10,00, empty, and malformed input?
7. What is the total source size — small enough to vendor or reimplement with confidence?

Integration Approach

Stack fit. Appropriate for a Laravel + Filament admin serving Brazilian users, e.g. back-office price/amount entry for e-commerce or ERP-adjacent tooling. It is not a fit for storefront, checkout, or public-facing forms, where a dedicated money-input library with broader community support is preferable.

Migration path. Start with a bounded spike on a branch: install, inspect src/ and composer.json, then wire exactly one form field against a real column. Do not roll out to multiple resources until the persistence contract is proven. Pin ^1.0 (or an exact version) — never a floating constraint — because upstream release notes are not a reliable signal.

Compatibility check. Before writing form code, verify the package's Filament/Laravel/Livewire/PHP constraints against our composer.lock. Assume it does not support a Filament major it was not built against; a patch release will not have widened it. If we are on Filament v4 and the package targets v3, stop and evaluate alternatives.

Storage convention (decide up front). Choose one and enforce it in the model cast:

• Integer cents (bigInteger) with protected $casts = ['price' => 'integer'], or
• decimal(15,2) with a matching decimal cast.

Never float. If the field dehydrates to cents, do not add a custom dehydrateStateUsing; if it emits a masked or decimal string, convert exactly once at the dehydration boundary and document that boundary.

Sequencing.

1. Branch spike: install pinned version, read source, confirm dehydration behavior and extension points.
2. Wire a single BrlMoneyField into one resource form; pair with a table TextColumn::make('price')->money('BRL', divideBy: 100) for display.
3. Write persistence tests via Livewire (fillForm with 0, 1.234,56, -10,00, empty; assert the raw DB value), not unit tests of the mask.
4. Confirm mask survives $refresh and dependent-field updates; add custom validation that normalizes before checking sign/range.
5. Only then extend to additional resources, and record the storage convention and normalization rule in team docs.
6. Keep a fallback ready: vendor the field class into our codebase, or replace with a plain Filament TextInput + Alpine mask.

Operational Impact

Maintenance. Our ongoing maintenance is near zero; the risk sits upstream. A single-maintainer, 1-star package with diff-only release notes means we cannot rely on timely fixes for Filament upgrades or locale bugs. Mitigation: pin the version, review each upstream diff before bumping, and treat vendoring/forking as a first-class option if usage spreads beyond one or two resources.

Support. No SLA, no community depth, no issue-tracker signal to rely on. Internal owners must be able to read and patch the field themselves. If the team cannot commit to that, this package is not appropriate for anything business-critical.

Scaling. Negligible performance footprint — client-side masking plus Livewire hydration, no queries, no background work. It does not affect horizontal scaling. The scaling concern is organizational: every additional form using the field multiplies the surface area exposed to a Filament upgrade.

Failure modes to watch.

• Mask reset or corrupted state after Livewire hydration/re-render.
• Double conversion (value ×100 twice) from adding dehydration on top of built-in behavior.
• Laravel numeric/decimal validation rejecting the masked string "1.234,56".
• Silent breakage on a Filament major upgrade if the version constraint is not re-verified.
• Missing ext-intl in production causing formatting divergence from local.
• Negative sign swallowed or empty input coerced to 0.

Ramp-up. Low for any engineer familiar with Filament — hours to first working field. The genuine learning curve is the money-state convention (masked string vs cents vs decimal), which must be documented explicitly rather than inferred. Budget a short internal note covering the storage convention, the single normalization point, and the test pattern; without it, the double-conversion failure mode will recur across the team.