Moeda Br Laravel Package

Technical Evaluation

Architecture fit

• The package's identity is ambiguous and must be resolved before any estimate: the repository description says it is a Laravel Nova custom mask field (a UI/admin-panel concern), while the supplied docs and prior assessments describe a framework-agnostic BRL formatting, parsing, and multiply/divide library (a domain concern). These are two different products, two different integration surfaces, and two different value cases. Treat the discrepancy as an open defect in the intake, not a detail.
• If it is the Nova field: fit is limited to back-office/admin screens. It has zero bearing on checkout, pricing, invoicing, or any persisted monetary value, and it adds a hard dependency on Nova (a paid, separately-versioned product) for any environment that must run it.
• If it is the currency utility: fit is reasonable for a Brazil-only product that needs R$ 1.234,56 display and input parsing. It is a convenience layer, not a money-handling foundation — the docs describe parsing localized strings back into floats, and float-backed money is the single most common source of downstream rounding and reconciliation defects.
• The multiply/divide actions in 3.2.1 are thin wrappers. They do not by themselves justify a dependency; integer minor units or an established money library provides the same coverage with stronger guarantees and a larger maintainer base.

Integration feasibility

• Low technical effort in either interpretation: Composer install, auto-discovered service provider, optional config publish. A competent Laravel developer can spike both paths in under a day.
• The real cost is not integration, it is decision and verification overhead: confirming which package we are actually adopting, whether Nova is in our stack, whether float returns are acceptable at our service boundary, and whether the arithmetic semantics match our rounding policy.
• No heavyweight dependencies reported, which keeps the blast radius small and makes removal cheap.

Technical risk

• Bus factor 1 / abandonment risk (high). Zero stars, single maintainer, no visible governance or release cadence beyond one patch in late 2024. For anything touching revenue-bearing numbers, this is the dominant risk.
• Semantic ambiguity risk (high). The Nova-vs-utility conflict means our own documentation, procurement, and security review may be evaluating the wrong artifact.
• Precision risk (medium-high). Float round-tripping for currency is a known anti-pattern. Even if we adopt for display, we must not let its parsed values become the system of record.
• Silent behavior change risk (medium). A patch note reading "improvements on multiply and divide actions" is not a specification. Rounding scale, exception behavior, and overflow handling can shift under a ^3.x constraint without a major-version signal.
• Vendor-surface risk (medium). If Nova is involved, we inherit Nova's licensing and upgrade cadence on top of this package's.

Key questions

1. Is this a Nova field, a currency utility, or both bundled? Which artifact does composer require actually deliver, and which does the README document?
2. Do we run Laravel Nova anywhere, and is the target surface admin-only or customer-facing/domain?
3. Does the package return floats from parsing, and if so, is any persisted monetary value derived from it?
4. What are the exact rounding, scale, overflow, and divide-by-zero semantics, and are they covered by the package's tests?
5. What is the intended version pin, and who owns re-running arithmetic regression tests on upgrade?
6. Build-vs-buy: intl's NumberFormatter with pt_BR covers formatting in roughly a day of work; is a zero-star dependency cheaper than ~2–3 days of first-party code and permanent ownership?
7. Is the product Brazil-only for the foreseeable roadmap, or is multi-currency on the horizon (in which case a locale-specific helper is a dead end)?

Integration Approach

Stack fit

• Fits a standard Laravel/PHP application either way; no exotic runtime requirements reported.
• If Nova-scoped, restrict usage to admin/presentation layers and document that explicitly so it never leaks into domain services.
• If domain-scoped, use it strictly at the edges: formatting for output, parsing at the request boundary via a Form Request/DTO that immediately converts to integer minor units. Do not let it become the arithmetic engine for pricing, tax, or ledger writes.
• For money-of-record arithmetic, prefer integer minor units plus an established library (e.g., moneyphp/money or brick/money), and treat this package as a presentation convenience only.

Migration path

• Nothing to migrate if adopted greenfield; it is additive.
• If replacing existing ad-hoc number_format calls, inventory them first — scattered formatting is usually the reason a "formatting inconsistency" ticket exists, and consolidating is where most of the actual value sits, independent of which library wins.
• If later removing the package, the exit cost is low provided we have not used its parsed floats as persisted values. Enforce that constraint from day one so the dependency stays reversible.

Compatibility

• Pin explicitly (3.2.* or exact) rather than a loose constraint, and commit the lockfile. Arithmetic-adjacent patches deserve the same scrutiny as schema changes.
• Verify PHP and Laravel version support against our supported matrix, and — if Nova is in scope — verify the Nova major version alignment, since Nova majors have historically moved independently of Laravel.
• Confirm intl/locale availability in the runtime image before betting on any fallback formatting strategy.

Sequencing

1. Resolve the artifact question (one day, owner: engineering lead). Everything downstream is blocked on this.
2. Timeboxed spike (1–2 days): install, exercise format/parse and multiply/divide against our real edge cases — zero, negatives, large values, rounding boundaries, divide-by-zero.
3. Build-vs-buy comparison against intl formatting plus a money library, using measured spike output rather than vendor claims.
4. Decide and record the outcome as an ADR, including the pin, the allowed usage boundary, and the fallback if the package is abandoned.
5. Implement behind a first-party interface (e.g., a CurrencyFormatter contract) so the vendor is swappable without touching call sites.
6. Regression suite with data providers mirroring the package's own tests, wired into CI before the first production use.

Operational Impact

Maintenance

• Expected ongoing cost is low in code and moderate in attention: a zero-star, single-maintainer package will not surface its own bugs, so we own discovery. Budget a small recurring review of releases and a re-run of arithmetic regression tests per upgrade.
• Wrapping behind a first-party interface converts a potential fork-and-maintain obligation into a routine swap, which is the main lever for keeping TCO near zero.

Support

• No commercial support, no SLA, no community depth to lean on. Internal escalation path must terminate with our own engineers.
• Assign a named owner (an individual, not a team) for the dependency; unowned dependencies are how stale pins become incidents.

Scaling

• Formatting and parsing scale trivially — CPU-negligible, no I/O, no state.
• The scaling concern is organizational, not technical: every additional service or repo that adopts it multiplies the version-pinning and upgrade-testing surface. Prefer a single internal formatting utility that wraps the dependency over direct adoption in N codebases.
• If Nova-scoped, scaling is bounded by admin traffic and is effectively a non-issue.

Failure modes

• Abandonment — no updates for a future PHP/Laravel major; mitigated by the interface wrapper and a written fallback plan.
• Precision drift — floats entering persisted totals, producing cent-level discrepancies that surface late in reconciliation; mitigated by an explicit integer-minor-units rule at the service boundary.
• Silent arithmetic change — a patch alters rounding or exception behavior; mitigated by exact pinning and CI regression tests.
• Divide-by-zero ambiguity — behavior is undocumented in the release notes; must be decided and handled explicitly at the service boundary rather than inherited.
• Wrong-artifact adoption — we integrate the utility while stakeholders believe we shipped the Nova field (or vice versa); mitigated by resolving the identity question before commitment.
• Config cache staleness — published config not refreshed at deploy, producing local-vs-production divergence.

Ramp-up

• Near-zero for any Laravel developer: small surface, plain API, no new mental model beyond the usage boundary rules.
• The ramp-up that matters is policy, not syntax: one short written standard covering "format at the edges, integer minor units in the domain, pin exactly, never persist parsed floats." That single page prevents most of the failure modes above.
• If Nova is in scope, add a short note on when the field is appropriate (admin forms) versus when server-side validation and normalization are still required — a mask is a UX affordance, not input validation.

TPM recommendation: Conditional adopt, scoped to presentation. Proceed only after the Nova-vs-utility ambiguity is resolved. If the need is BRL display and input parsing in a Brazil-only product, adopt with an exact pin behind a first-party interface. If the need is money-of-record arithmetic, decline and standardize on integer minor units with an established money library — the 3.2.1 "improvements to multiply and divide" do not change that calculus, and zero stars plus float-returning parsers is not a foundation for revenue-bearing numbers.