Moeda Br Laravel Package

Product Decisions This Supports

• Market localization for Brazil. If the roadmap includes Brazilian customers or a BR-facing back office, this package removes a recurring papercut: admins typing and reading R$ 1.234,56 correctly instead of US-format 1,234.56. That is a small but visible quality signal in a localized product.
• Back-office UX consistency. A Nova field enforces one currency input/display convention across every resource, instead of each developer hand-rolling masks, accessors, and formatters that drift apart. This is a standardization decision, not a feature decision.
• Build vs. buy vs. ignore. The build cost is genuinely low (a Nova Field subclass plus a formatter). The real decision is whether a 0-star, single-maintainer dependency belongs in your composer.json for a purely cosmetic concern. For most teams the honest answer is: acceptable only if Nova is already a paid, non-critical part of your admin stack — otherwise write 30 lines yourself.
• Scoping the money problem correctly. Important: this package is a mask/formatting field. It does not solve monetary arithmetic, rounding, or precision. Product decisions about pricing engines, tax calculation, invoicing, or FX must be routed to a real money library (moneyphp/money or brick/money) and integer minor units. Do not let a formatting package get conflated with a financial-correctness decision — that is the single biggest misread risk here.
• Dependency-governance precedent. Adopting it sets a precedent for how small, unmaintained packages enter the codebase. Worth deciding explicitly rather than case-by-case.

Diligence flag: the supplied materials are internally inconsistent. The package is described as a Laravel Nova custom mask field, but the prose description claims a framework-agnostic formatting/parsing library, and the engineering assessment discusses Multiply/Divide actions that appear to belong to a different package entirely. Confirm from the actual repository and README what it does before it enters a roadmap or an estimate.

When to Consider This Package

Adopt when all of the following hold:

• You already run Laravel Nova (it is useless otherwise — it is a Nova field, not a general formatter).
• Your admin surface is single-currency BRL and likely to stay that way.
• The field is used for display and data entry only — it never feeds a calculation path without a separate, tested normalization step.
• Your team accepts a low-maintenance dependency: zero stars, one maintainer, last release October 2024. Treat it as vendored code you may need to fork.

Look elsewhere — or just write the field yourself — when:

• You are not on Nova, or you are on Nova and need more than a mask (validation rules, minor-unit storage, currency switching).
• You need multi-currency support, exchange rates, or locale-aware formatting beyond pt-BR.
• You need monetary arithmetic: rounding modes, allocation, tax, installments (parcelas), or anything where a one-cent error is a support ticket or a compliance issue.
• You need an audited or supported dependency — procurement, SOC 2, or a security review will not look kindly on an unmaintained single-author package for anything revenue-adjacent.
• Your finance team already dictates storage in integer centavos; in that case a Nova field plus a model cast is a cleaner, fully-owned solution.

How to Pitch It (Stakeholders)

Executives (one paragraph): For our Brazilian back office, this is a small, low-cost polish item — it makes currency entry and display correct and consistent for BR staff, which reduces data-entry mistakes and looks professional to local customers. It is a display-layer tool only; it does not touch pricing, billing, or any calculation, so the risk exposure is limited to an admin form field. It is a zero-star, single-maintainer package, so we recommend a time-boxed spike and a fallback plan to own the code ourselves if the dependency stalls. Cost: roughly a day of engineering, no licensing spend.

Engineering (one paragraph): It is a Nova Field for BRL masking/formatting — nothing more. Pin it to a narrow version constraint, restrict usage to Nova resources, and never let raw masked strings into arithmetic; normalize to integer centavos at the request boundary. Before adopting, read the actual source and README — the supplied descriptions conflict on whether this is Nova-only or framework-agnostic, and the release note for 3.2.1 ("improvements on multiply and divide actions") does not match a mask field, so verify what 3.2.1 actually changed. If the package turns out to be thinner than expected, the replacement is a ~30-line custom field plus a formatter in our own namespace — budget for that outcome rather than assuming the dependency is permanent.