- How do I install vyuldashev/nova-money-field?
- Install it with Composer via composer require vyuldashev/nova-money-field. There are no migrations, no publishable config file, and no service provider ceremony, so adoption is just the Composer require plus a few lines in your Nova resource's fields() method. You will also need a paid Nova license and a Nova installation that satisfies the package's declared version constraint.
- Does nova-money-field store amounts as integers or decimals?
- The field itself is a presentation-layer adapter and delegates value semantics to moneyphp/money, so the storage format is decided by your model attribute and casts, not by the package. You must pick either integer minor units with a paired currency column or a decimal major-unit column, and be consistent everywhere. Mixing the two is the classic cause of 100x display and persistence bugs. Make this decision explicitly before data exists, because it is effectively irreversible.
- How do I set the currency for a money field in Nova?
- The documented pattern is to chain currency() on the field, for example Money::make('Price')->currency('USD'). Whether the currency can resolve per record via a closure over the resource is not clearly documented, so verify that behaviour against src/Money.php before relying on it. If you need dynamic currencies, test the resolve() and fill() paths in a POC first.
- Which Laravel Nova versions does this package support?
- Nova is closed source and ships breaking majors, and this field wraps a custom frontend component, so compatibility is version-sensitive. Check the composer.json constraint in the repository and confirm the component matches your installed Nova release. There is no evidence of a CI matrix proving support against current Nova builds, so pin the package and re-test money inputs after every Nova upgrade.
- Which moneyphp/money version does it require?
- The required moneyphp/money range is declared in the package's composer.json, so check that constraint before installing. If your domain layer already depends on moneyphp/money, run a Composer dry-run update to confirm the ranges resolve without conflict. Version skew here can also affect formatting output because the formatter relies on ICU locale data.
- Does the field add validation rules automatically?
- Do not assume it does. The package is a display and edit adapter, so numeric, min, max, and required constraints should be added explicitly with ->rules() on the field. Verify whether any rules are emitted by reading src/Money.php. Adding your own rules is the safe default for monetary inputs.
- How does nova-money-field handle null, zero, and negative amounts?
- These semantics are not documented in the README and must be verified against the resolve() and fill() methods in src/Money.php. Test each case explicitly in your own Nova resource, including what happens when the underlying currency column is missing or empty. Treating these edge cases as unknown until proven is the correct posture for monetary data.
- Can I use nova-money-field outside Nova, for example in Inertia, Livewire, or an API?
- No. It is a Nova field, so it only applies to Nova resource forms and index views. Money rendered in Inertia, Livewire, Blade, or API responses should be formatted in your domain or presentation layer using moneyphp/money directly. Using this package everywhere would create a second source of truth for formatting, so scope it as admin-only.
- Does the package need migrations, config publishing, or a service provider?
- No. Adoption is a Composer require, a decision about how your model casts the money attribute, and a few lines in your resource's fields() method. There is no config file to publish and no migration to run, which is why a proof of concept takes well under a day. The real effort is the storage-format decision, not the package wiring.
- Is vyuldashev/nova-money-field actively maintained, and what are the alternatives?
- It is a single-maintainer package with a small star count and effectively no dependents, so treat abandonment as a when rather than an if. There is no vendor support, SLA, or security review paperwork, which will not survive procurement scrutiny in a regulated environment. Reasonable alternatives are writing a small in-house Nova field over moneyphp/money or choosing a more actively maintained money field package, and either way you should keep money formatting out of your domain layer boundaries.