Moeda Real Laravel Package

Technical Evaluation

Architecture fit. stonkeep/moeda-real is a Laravel Nova field — a presentation-layer component (a PHP Field class plus a Vue component) that renders a value inside a Nova resource. It is not a general currency library, not a domain model, and not a service. That means its architectural footprint is deliberately narrow: it sits between your Eloquent attribute and the Nova UI. It fits only if three conditions are simultaneously true — you run Laravel, you have a Nova license and an active Nova admin panel, and you specifically need Brazilian Real (BRL) presentation/input behavior. The name ("moeda real") and the stonkeep vendor prefix suggest an in-house package published publicly rather than a community library built for general adoption, which is consistent with the 0 stars / 0 dependents signal.

Integration feasibility. Mechanically trivial: a composer require, a use statement, and one line in a Nova resource's fields() method. The real feasibility question is not "can we install it" but "can we depend on it." With zero dependents and zero stars there is no evidence of production use anywhere outside the author's own application, so there is no field-tested path. Expect to spend more time reading the source than integrating it — which, for a package this small, is on the order of minutes.

Technical risk. This is the dominant concern and it is almost entirely supply-chain and lifecycle risk, not runtime risk:

• Bus factor of one. Single maintainer, no visible community, no dependents. Abandonment is the base case, not the tail case.
• Nova major-version coupling. Nova's field API has shifted across major versions (notably Vue 2 → Vue 3 and related tooling changes around Nova 4). A field built for one Nova major will not necessarily work on the next, and the failure mode on upgrade can be a broken UI rather than a clean exception.
• Correctness risk is asymmetric. A formatting bug in a currency field is not cosmetic — it displays wrong money to finance/ops users. Rounding, thousands separators, cents-vs-decimal storage, and locale assumptions are the exact places these fields break.
• Ambiguous scope. "A Laravel Nova field" tells us nothing about whether it is display-only or also handles input masking, and nothing about how it expects the underlying column to be stored (integer cents vs. decimal vs. string).
• Distribution risk. Confirm Packagist availability and a license file; a package that is installable only via a VCS repository is a materially different (worse) dependency.

Key questions to resolve before any commitment.

1. Which Nova major versions are supported, and what are the composer.json constraints for PHP, Laravel, and laravel/nova?
2. Is this display-only, input-only, or both? Does it mask/format on write, and does it round-trip cleanly?
3. What storage format does it assume (integer minor units vs. decimal)? Does it match our existing schema?
4. Is the locale hardcoded to pt-BR / R$, or configurable? Does it handle negative values, nulls, and large magnitudes?
5. Is there a license, a changelog, and any tests? Is the repository published on Packagist with tagged releases, or is it a raw VCS entry?
6. Is the maintainer willing to accept issues/PRs, or is this effectively code we would adopt and own?

Integration Approach

Stack fit. Green-field compatibility is binary: Laravel + Nova → potentially viable; anything else → not applicable. There is no partial fit. If our admin surface is Filament, Livewire, Inertia, or a bespoke SPA, this package contributes nothing and should be closed out immediately.

Migration path. Treat this as code adoption, not dependency adoption. The recommended path is to read the source (it is small), vendor the field into our own namespace as an internal App\Nova\Fields\MoedaReal or equivalent, and keep the upstream repository as a reference rather than a Composer requirement. This converts an unmaintained third-party risk into a controlled internal artifact we can patch, test, and upgrade on our own Nova cadence. If we do take it as a dependency, pin an exact version (no caret range) and commit the lockfile.

Compatibility. Validate against the specific Nova major we run, not "Nova" generically. Build a throwaway Nova resource in a scratch environment that exercises the field in index, detail, and form contexts — these are three different rendering paths and a field can work in one and fail in another. Confirm the built assets compile under our Node/Vite toolchain if we rebuild them.

Sequencing.

1. Spike (½ day). Install in a non-production branch, render against seeded fixture data covering positives, negatives, zero, null, and values above R$ 1.000.000.
2. Correctness gate. Compare field output against an independently computed expected string. This is the go/no-go.
3. Decide build-vs-borrow. If the spike passes, vendor the code internally. If it fails, the fallback is small: Nova's native Number field with a displayUsing callback covers display-only BRL formatting in a few lines.
4. Pilot. Apply to a single low-stakes Nova resource; observe for a release cycle.
5. Broaden. Roll out resource by resource, never as a big-bang change.

Operational Impact

Maintenance. Assume we own it from day one. Budget a recurring line item for Nova upgrade testing — this is the predictable breakage point, and it will recur with every Nova major. A vendored copy removes the "will the package update" question but adds "did we remember to patch our copy," which is the cheaper of the two problems for a component this size.

Support. There is no support contract, no SLA, no community to search when something breaks, and no dependents to indicate someone else has already hit our bug. Escalation path is: read the source, or ask the maintainer directly and hope. Plan accordingly — do not put this on a path where a blocked field blocks a release.

Scaling. Negligible. This is a UI field with no runtime, no I/O, no background work, and no data-path involvement. It does not affect throughput, queue depth, or database load. The only scaling-adjacent concern is asset build time, which is immaterial. Note the inverse risk: because it is invisible at scale, a formatting defect will scale silently across every record rather than announcing itself.

Failure modes.

• Silent display corruption — wrong separators, wrong rounding, or a cents/decimal mismatch shows incorrect money without erroring. Highest-severity mode; caught only by explicit assertion tests.
• Upgrade breakage — Nova major bump renders the component blank or throws at runtime, typically discovered in staging or, worse, by an admin user.
• Abandonment / delisting — repository archived or removed from Packagist; a fresh composer install fails on a clean machine. Mitigated entirely by vendoring or by committing to a private mirror.
• Locale leakage — hardcoded pt-BR behavior produces wrong output the first time we operate in another currency or locale, and it will look like a data bug rather than a field bug.

Ramp-up. Very low — measured in hours, not days. Any Laravel developer can read a Nova field in one sitting; there is no new paradigm, no new runtime, no new deployment surface. The training cost is not in learning the package, it is in learning to distrust it: establish a team norm that currency formatting is always validated against expected output in tests, never eyeballed in the UI.

TPM recommendation. Do not add this as a production dependency at its current maturity signal. Either (a) vendor the source internally and own it, or (b) skip it and implement BRL formatting with Nova's native field plus a display callback — a few lines of code with no supply-chain exposure. The package's value is as a reference implementation, not as a dependency.