masoudi/number-plus
number-plus is a Laravel/PHP package that simplifies number handling with convenient formatting and conversion helpers. It supports locale-aware numerals, currency, and human-readable output, making numeric display cleaner and more consistent across applications.
This package is a Laravel Nova custom field, so "getting started" means installing it into a Nova app first — not a plain Laravel app. It was last released 2023-05-17 and the repository is archived, so treat the install as a vendor-and-forget operation rather than a normal Composer dependency.
Minimal steps:
laravel/nova registered:
composer require masoudi/number-plus
composer require masoudi/number-plus:^1.0 --with-all-dependencies and be ready to adjust.vendor/masoudi/number-plus/composer.json and the field class under src/ to get the real namespace — with 1 star and 0 dependents, do not trust any README snippet without verifying the class path.fields() method:
use Masoudi\NumberPlus\NumberPlus; // verify actual namespace
public function fields(NovaRequest $request)
{
return [
NumberPlus::make('Price'),
];
}
Where to look first: the package's Vue component (usually under resources/js/ or dist/js/) and the PHP field class. Those two files are the package. There is no documentation ecosystem to fall back on.
First practical use case: replacing Nova's built-in Number::make() with something that formats large values (thousands separators, fixed decimals, prefix/suffix) while still submitting a clean numeric value. That is the only defensible reason to adopt an unmaintained field like this — if you just need a number input, use Nova's built-in Number field and skip the risk entirely.
Because the package is archived and has no documented API surface, the patterns below center on containing the dependency rather than exploiting its full feature set.
Use it as a drop-in field, validated server-side anyway. Nova fields are presentation + hydration only. Put the real rules in your resource:
NumberPlus::make('Amount')
->rules('required', 'numeric', 'min:0', 'max:1000000'),
Never rely on field-level min/max/step configuration for correctness — they are UI hints, not validation.
Centralize the field configuration. If you end up using it on more than one resource, wrap it:
// app/Nova/Fields/MoneyInput.php
namespace App\Nova\Fields;
use Masoudi\NumberPlus\NumberPlus;
class MoneyInput extends NumberPlus
{
public function __construct($name, $attribute = null, $resolveCallback = null)
{
parent::__construct($name, $attribute, $resolveCallback);
// apply your app-wide formatting defaults here
}
}
This gives you one file to patch if the field breaks after a Nova upgrade, instead of hunting through every resource.
Pair with an accessor/mutator on the model. If the field submits a formatted string (e.g. "1,234.50"), strip it before persistence:
protected function amount(): Attribute
{
return Attribute::make(
set: ?fn ($value) => is_string($value) ? (float) str_replace(',', '', $value) : $value,
);
}
This is defensive: you don't know what the Vue component sends until you inspect a network request in Nova's dev tools.
Integration tip — isolation on index/detail. Custom fields are most fragile on the index and detail views (they render differently from forms). If the field misbehaves on index, fall back to a plain text or Number field for those views and keep NumberPlus only on forms:
NumberPlus::make('Amount')
->hideFromIndex()
->hideFromDetail(),
Migration path pattern. Because this package is abandoned, the honest pattern is: use it only behind a wrapper class so that swapping to Nova's Number field (or a maintained alternative) is a one-file change per resource.
Archived + 1 star + 0 dependents is the headline risk. No security updates, no Nova 5 compatibility guarantees, and effectively no community to ask. If this is going into production, fork it into your own org's namespace and maintain it, or don't adopt it.
Nova version drift is the main failure mode. Nova changes its field base class and Vue toolchain between majors. A field compiled in 2023 will often render broken on newer Nova. Diagnosis: open browser dev tools, watch for Vue errors or a 404 on the compiled JS asset in /nova-vendor/....
Asset publishing / nova:assets. If the field's JS doesn't load, run php artisan nova:assets (or nova:publish) and check public/vendor/.... Custom Nova fields live their own compiled asset; a missing or stale dist/ is a common "blank field" cause.
Number formatting vs. locale. "Advanced" number fields frequently format client-side. That means what the user sees (1.234,56 in EU locales) may differ from what's submitted. Inspect the actual form payload in the Network tab before trusting it — don't assume the value arrives as a clean float.
Int vs. float precision. For money, prefer storing minor units (integers) in your schema and format at display. Any custom number field that does decimal math in JS will bite you at scale. Validate server-side with decimal: or integer rules accordingly.
Extension points. The realistic ones are: subclass the PHP field class and override resolve/fill, or override the JS component if you're willing to rebuild the Vue bundle. Since the repo is archived, forking and editing the Vue source directly is often faster than trying to extend.
Debugging checklist. (1) Does the field appear at all? → registration/namespace. (2) Does it appear but render blank? → compiled asset / Nova version. (3) Does it render but not save? → fill() / mutator mismatch. (4) Does it save but show the wrong value? → formatting vs. storage mismatch.
Abandoned-package hygiene. Add it to an allowlist if you run composer audit or composer-unused, and pin an exact version in composer.json so a future tag (unlikely) can't silently change behavior.
How can I help you explore Laravel packages today?