Filament Brl Money Field Laravel Package

Product Decisions This Supports

• Localized commerce/admin UX for the Brazilian market. If the roadmap includes BRL pricing, invoicing, or a Brazilian customer base, this field removes a recurring papercut in every admin form where operators type currency: R$ 1.234,56 instead of raw decimals, with locale-correct parsing.
• Build vs. buy for form-level money input. The alternative is writing and maintaining a custom Filament mask/parser (masking, thousands separators, Livewire hydration, validation interplay, negative/zero edge cases). Building that in-house typically costs several days plus ongoing maintenance across Filament upgrades. This package is a candidate "buy" at near-zero cost — but only if the compatibility and persistence risks are contained.
• Accelerating internal CRUD/admin delivery. For back-office screens (product prices, plan amounts, freight costs, invoice line items), a drop-in field reduces per-form implementation time and keeps editing behavior consistent across resources.
• Informing an i18n / multi-currency roadmap decision. Adopting a single-locale field is a tactical win, but it's also a signal: if multi-currency is on the horizon, decide now whether to standardize on a money abstraction (e.g., integer minor units + a formatting layer) rather than accumulating per-locale field packages.
• Data-integrity decision point. The package forces an explicit choice — store integer cents or decimal(15,2), and convert exactly once at the dehydration boundary. That's a product-relevant decision (reporting, exports, accounting reconciliation), not just an engineering detail.
• Vendor/fork contingency planning. With 1 star, a single apparent maintainer, and a patch-only release history, the realistic product stance is "adopt as a thin, replaceable dependency we are prepared to own," which shapes how much surface area we allow it to cover.

When to Consider This Package

Consider it when all of the following hold:

• The admin surface is Filament (v3 or v4 — verify the composer.json constraint explicitly; do not assume a patch release widened it) and forms are built with Filament fields.
• The product is BRL-only, or BRL is the only localized currency input needed in the near term.
• The team wants to avoid maintaining custom masking/parsing code and accepts a small third-party dependency for a narrow, non-critical UI concern.
• You can isolate and test the persistence boundary: one smoke test per money field covering 0, 1.234,56, negative, and empty input, asserting the stored database value (not just the rendered input).
• You are willing to pin ^1.0, review the v1.0.0...v1.0.1 diff once, and vendor or fork if the maintainer goes quiet.

Look elsewhere (or build a small internal field) when:

• Filament compatibility is unconfirmed for your version — a broken field in a payment/pricing form is a worse outcome than a day of in-house work.
• Multi-currency or multi-locale input is required; a single-locale field will not scale and will fragment your money handling.
• You need support guarantees, security review, or an SLA. A 1-star package with no published changelog detail beyond a diff link does not offer that.
• Your app already has a money abstraction (moneyphp/money, Brick\Money, or a house decimal type). Introducing a string-mask field on top creates two competing representations and double-conversion risk.
• The field's dehydration behavior is undocumented or ambiguous. If you cannot quickly confirm whether it dehydrates to cents or to a formatted string, the dehydrateStateUsing() trap (double ×100) becomes a live production risk.
• Accounting/reporting correctness is high-stakes and the field would be the primary write path for monetary values without a dedicated normalization layer and tests.

How to Pitch It (Stakeholders)

For executives (30 seconds). This is a small, MIT-licensed UI component that gives our Filament admin the familiar Brazilian currency input (R$ 1.234,56) and stores clean decimals — instead of us hand-building and maintaining that formatting logic in every form. It's cheap to try and cheap to remove. The real risks are not financial: they're (a) compatibility with our Filament version and (b) getting the display-to-database conversion right. We mitigate both with a short, timeboxed spike and one persistence test per money field. Recommendation: approve a 1–2 day evaluation, adopt only behind tests, and treat the code as something we could own if the maintainer disappears.

For engineering. Drop-in Filament form component; no config necessarily required (publish if a config tag exists). Before writing form code: confirm the Filament/Laravel/Livewire/PHP constraints in composer.json, inspect src/ for the field class and fluent methods, and determine whether dehydration to cents is built in — if it is, adding our own dehydrateStateUsing() multiplies by 100 twice. Standardize on integer cents (bigInteger) or decimal(15,2) — never float — and convert exactly once at the dehydration boundary, mirrored by a matching model cast. Remember validation sees the masked string, so numeric/decimal rules won't work; normalize before validating or use a custom rule. Confirm the mask survives Livewire hydration (->call('$refresh')) and test negative, zero, and empty input. Pin ^1.0, review the v1.0.1 diff once, and add integration tests through a Livewire form component that assert the stored value. Because the package is small and low-adoption, keep it behind a thin internal wrapper (or a forked namespace) so it can be replaced without touching every resource.