Nova Money Field Laravel Package

Getting Started

1. Install into a Nova app (Nova 4/5 assumed — verify compatibility in composer.json):

   composer require everestmx/nova-money-field
   

   No service provider registration is normally required for a Nova field, but check src/ for one before assuming.

2. Locate the field class first. With a low-profile package, the README is often thinner than the code. Open:

   • src/ — find the class extending Laravel\Nova\Fields\Field
   • resources/js/ — find the Vue component referenced by $component
   • composer.json — confirm the PSR-4 namespace and Nova version constraint

3. First use case — a price stored in minor units. A money field is typically used when your database stores an integer (cents/paise) but users should see a formatted currency amount:

   use EverestMX\NovaMoneyField\Money; // confirm actual namespace
   
   public function fields(NovaRequest $request): array
   {
       return [
           Money::make('Price')
               ->currency('USD')
               ->rules('required', 'integer', 'min:0'),
       ];
   }
   

4. Validate the round trip immediately. Create a record with a value like 10.50, save, and inspect the raw database column. This tells you whether the field converts to minor units on write or expects you to store them yourself — the single most important behaviour to establish before building on it.

Implementation Patterns

Pair with model casts / accessors. The safest pattern is to let the field handle display only and keep conversion explicit in the model:

protected $casts = ['price_cents' => 'integer'];

public function getPriceAttribute(): float
{
    return $this->price_cents / 100;
}

Then point the field at the accessor and add a mutator that multiplies back to cents. This survives the package being abandoned.

Format per context. Most Nova money fields expose formatting methods. Typical patterns to check for:

Money::make('Price')->currency('EUR')->decimals(2)
Money::make('Budget')->asMinorUnits()   // if supported
Money::make('Fee')->displayUsing(fn ($value) => number_format($value / 100, 2))

displayUsing is the escape hatch if the built-in formatting doesn't fit — it works on any Nova field that resolves a value for index/detail.

Currency as a second column. For multi-currency apps, don't hard-code ->currency() in the resource. Read it from the model or a related setting:

Money::make('Amount')->currency(fn () => $this->currency_code ?? 'USD')

Confirm the field supports a closure before relying on it; otherwise use resolveUsing.

Combine with validation and nullable. Nova fields pass values through request validation, so keep numeric/integer rules aligned with what the component submits. A money input that submits "1,234.56" will fail an integer rule — test the exact payload in the network tab.

Sorting and filtering. If the underlying column is in minor units but the field displays major units, ->sortable() sorts on the raw integer, which is usually correct. Be careful with any filterable() you add — filter values must match the stored representation, not the displayed one.

Index vs form. Check that the Vue component degrades gracefully in read-only contexts (index, detail, preview). Money fields sometimes ship a form-only component that renders blank on the index.

Gotchas and Tips

• This is a zero-signal package (0 stars, 0 dependents, no score). Treat it as unmaintained: pin the version, read the source before upgrading Nova, and be prepared to fork. Do not build critical billing UI on it without a fallback.
• Minor vs major units is the classic trap. There is no universal convention; some money fields store cents, others store decimals. Verify by saving 1.00 and 100 and inspecting the database both times.
• Asset publishing. If the Vue component isn't compiled into the package's dist/, you may need php artisan nova:publish or npm run dev inside the package. A blank field in the browser usually means a missing JS asset, not a broken backend.
• Locale and thousand separators. number_format in PHP and the JS formatter can disagree. If the input shows 1.234,56 but PHP expects 1234.56, values will be silently mangled. Test with a locale that uses a comma decimal separator.
• Float precision. Never round-trip money through float casts for storage. If the field submits a decimal string, convert with (int) round($value * 100) in the mutator, or use a money library such as brick/money behind an accessor.
• Nova version drift. Fields built for Nova 3 often break on Nova 4/5 due to the Field base class and Vue 3 migration. Check the nova constraint in composer.json against your installed version.
• Debugging checklist when the field misbehaves: (1) confirm the field class renders at all with ->help('debug'); (2) open browser devtools and inspect the submitted value; (3) dd() the value inside resolveUsing; (4) check nova-components/ isn't shadowing the vendor copy.
• Extension points. If the package is too thin, subclass it and override resolve/fill rather than editing vendor files — this keeps your fork or upgrade path clean. For anything complex, a plain Text/Number field plus a model accessor is often more predictable than a third-party money field.