Nova Money Field Laravel Package

Technical Evaluation

• Initial assessment triggered by swiftmade/nova-money-field v1.5.0. The release adds support for moneyphp/money v4. This is a dependency-compatibility release, not a confirmed product feature; TPM should treat it as integration risk reduction and a potential unblocker for moneyphp v4 standardization.
• Architecture fit: Good fit where the application already uses Laravel Nova for admin/back-office CRUD and needs first-class monetary input/display fields. The package should remain a Nova UI adapter; moneyphp/money should remain the domain representation for amount, currency, rounding, and formatting. Do not let the Nova field become the system of record or sole validation layer.
• Integration feasibility: Feasible if the stack is Laravel + Nova + moneyphp/money. Requires Composer constraint alignment across app, Nova, and this package. v1.5.0 matters most for teams blocked on moneyphp v4 or standardizing greenfield projects on v4. Confirm whether v1.5.0 supports both moneyphp v3 and v4 or only v4.
• Technical risk: Medium. Main risks are Composer dependency conflicts, Nova version lock, moneyphp v4 behavioral differences around parsing/rounding/serialization/currency, and sparse release-note detail. Semver suggests low breaking-change risk, but dependency support changes should still be regression-tested in representative Nova resources.
• Key questions: Which PHP, Laravel, Nova, and moneyphp versions are supported? Does v1.5.0 keep v3 compatibility? How are amounts persisted and rendered — minor units, decimal strings, or floats? Does the field preserve currency and locale formatting? Are validation rules and parsing behavior documented? Is there test coverage for moneyphp v4? What is the maintenance cadence and license posture?

Integration Approach

• Stack fit: Use in Laravel Nova resources for monetary form inputs and display. Keep API/domain persistence, casts, DTOs, and business validation in application code backed by moneyphp/money. Avoid coupling non-Nova workflows to the field package.
• Migration path: If currently on moneyphp v3, create an upgrade branch, inspect Composer constraints, update nova-money-field to v1.5.0, and then test Nova resource forms, detail/index views, validation, serialization, exports, and API boundaries. If greenfield, pin moneyphp v4 and this package version only after confirming the full compatibility matrix.
• Compatibility: Verify Composer constraints for PHP, Laravel, Nova, and moneyphp. Confirm whether v1.5.0 is additive or requires v4. Check Nova field asset publishing/build behavior after upgrade. Add CI coverage for representative currencies, amounts, locales, and invalid inputs.
• Sequencing: 1) Inventory all Nova resources using money fields; 2) validate dependency graph and Nova license constraints; 3) upgrade in non-production with representative data; 4) regression-test CRUD, validation, formatting, rounding, and currency handling; 5) pilot one resource behind a flag or limited rollout; 6) document conventions before broader adoption.

Operational Impact

• Maintenance: Small UI package surface area, but it sits on a third-party chain: Nova, Laravel, and moneyphp/money. v1.5.0 indicates active maintenance. TPM should track moneyphp and Nova release compatibility and budget periodic Composer updates plus targeted regression.
• Support: Support is likely community/GitHub-based unless internal ownership is assigned. Failures will usually appear as Nova form validation, formatting, or currency-display bugs. Assign an owner familiar with Laravel/Nova and money semantics.
• Scaling: Runtime scaling is low concern for an admin field. Operational scale is about the number of Nova resources and monetary edge cases. Enforce server-side validation and domain-level money rules; do not rely on the UI field alone.
• Failure modes: Composer dependency conflicts, moneyphp v4 behavior changes, rounding/formatting mismatches, currency parsing errors, Nova asset breakage after upgrade, and silent acceptance of invalid amounts. Mitigate with constrained versions, CI regression tests, and server-side validation.
• Ramp-up: Low for Laravel/Nova developers; moderate for teams needing moneyphp/money conventions. Provide examples for currency handling, minor units, locale formatting, and validation. Pilot with one resource and document usage patterns before wider rollout.