Nova Advanced Number Field Laravel Package

Product Decisions This Supports

• Back-office data quality as the product bet — not a new customer-facing feature. This is a Nova field that formats numeric inputs (thousands separators, configurable decimals, $ / % / unit prefixes and suffixes) and constrains entry with min / max / step. The measurable win is fewer mistyped prices, quantities, discounts, and rates in the admin panel, and fewer downstream correction tickets and reconciliation questions. Frame it as an internal-tooling investment with a quality metric attached, not a roadmap item.
• Build vs. buy on a narrow UI gap. The realistic in-house alternative is one to two days of custom Nova field work plus indefinite upkeep of a Vue component and its asset build. Against an MIT-licensed, single-field package, adoption is the default. Build only if your formatting model genuinely doesn't fit — see the locale caveat below.
• Scoping the actual requirement before committing. Nova's native Number field already covers min / max / step and basic display. The incremental value here is presentation: decimal precision, prefix/suffix unit clarity, and consistent rendering between form, detail, and index views. If the ticket is truly about validation, close it against native Nova. If it's "operators misread or mistrust the numbers on screen," this is the tool.
• Prioritizing where numeric clarity pays off. Good candidates to score against the roadmap: price and discount entry, quantity and stock adjustments, percentage/rate configuration, KPI and benchmark inputs, and any admin-editable number currently being typed into a loosely validated text field. Sequence the highest-traffic, highest-consequence field first (typically price) and expand only after it renders and saves correctly in staging.
• Sequencing behind the platform upgrade, never ahead of it. v3.3.0 requires PHP 8.2+, Laravel 12, and Nova 5, and explicitly drops PHP 8.1 and Laravel 10. If the Laravel 12 / Nova 5 upgrade is already funded, this rides along at near-zero marginal cost. If it isn't, this package is emphatically not a reason to trigger a platform upgrade — park it behind that milestone.
• Classifying vendor risk rather than avoiding it. 11 stars, 0 dependents, single maintainer, last release March 2025: real bus-factor exposure, but bounded. MIT license plus a one-class code surface makes the exit cost roughly an afternoon of forking or absorbing the field into app/Nova/Fields. The right posture is "adopt with a documented fork contingency," not "reject as unproven."
• Containing dependency debt through pinning. Pin explicitly in composer.json. Treat 3.2 → 3.3 as breaking for anyone on Laravel 10 / PHP 8.1; a floating ^3.0 lets a routine composer update silently cross the platform support floor. That's a self-inflicted incident, and it's a one-line policy to prevent.
• Keeping the formatting contract out of the field. The field formats inside Nova only. APIs, invoices, PDFs, emails, and exports need a shared canonical formatter (e.g. Number::currency() or a Money value object). Add it as a decision item: agree where rounding happens, and make the database column, model cast, and field precision agree — decimals(2) over a decimal(10,4) column hides data until accounting reconciliation finds it.

When to Consider This Package

Consider it when:

• You are already on, or formally committed to, PHP 8.2+ / Laravel 11–12 / Nova 5, and want formatted numeric inputs in admin resources.
• The requirement is genuinely currency or unit presentation, decimal precision, or prefix/suffix consistency across Nova forms, detail, and index views — not merely numeric bounds.
• You want a low-integration-cost admin UX and data-integrity improvement and are comfortable pinning an MIT dependency you could vendor in a day.
• You can assign an owner and fund a small manual UI regression pass on each Nova major bump. Nova's compiled-asset pipeline is the real recurring maintenance cost of any custom field; budget for it or don't adopt.
• Your admin panel is single-locale or accepts one fixed presentation. Prefixes and suffixes are static strings, not a locale-aware currency formatter — don't expect 1.234,56 € to appear because the app locale is de.

Look elsewhere when:

• You're on Laravel 10 / PHP 8.1 or Nova 4. Stay pinned to 3.2.x or defer entirely; do not upgrade the platform for this.
• The need is validation only — native Nova Number already does min / max / step. Adding a dependency for no presentation gain is unjustified.
• The requirement is "numbers look right everywhere" — API responses, exports, imports, PDFs. This covers roughly one surface; scope the rest as a separate shared-formatter workstream or don't start.
• You need true multi-locale numeric formatting inside the admin UI. That's a custom Vue component, at which point you own the asset build and the build-vs-buy math flips.
• Your team has no appetite for taking ownership of a low-star dependency, even with a fork plan. Reasonable; just make it an explicit decision rather than a silent rejection.

Adoption checklist before rollout: verify namespace and API surface by reading vendor/simplesquid/nova-advanced-number-field/src (not just the README); run composer why-not if resolution fails unexpectedly (Nova is a private repo — auth failures masquerade as dependency conflicts); swap one field first; validate index, detail, and form in staging; then centralise definitions via a MoneyNumber subclass so most call sites point at your class, not the vendor's namespace.

How to Pitch It (Stakeholders)

To executives — one paragraph: We can reduce a recurring class of back-office data errors — mistyped prices, quantities, and percentages — with a small, MIT-licensed add-on to our admin panel rather than custom development. It costs effectively nothing to integrate if we sequence it behind the Laravel 12 / Nova 5 upgrade we've already funded, and it carries no lock-in: worst case, the maintainer walks away and we absorb a single file into our codebase in an afternoon. The ask is not budget; it's permission to pin the dependency and a few hours of QA per Nova major release.

To engineering — the honest version: This is a Nova-only field with a one-class PHP surface and a compiled Vue component. It buys us decimal precision, prefix/suffix unit clarity, and consistent rendering across form and detail views — all things native Number doesn't do. Constraints to accept up front: (1) pin the version, because 3.3 drops PHP 8.1 and Laravel 10; (2) min/max/step are UX, not security — duplicate them as ->rules(...); (3) keep the DB column, model cast, and field decimals in agreement; (4) it formats nothing outside Nova, so pair it with a shared canonical formatter; (5) subclass it in-app so a future fork is a swap, not a refactor. Vendor risk is 11 stars and one maintainer — mitigated by MIT licensing and a deliberately small blast radius.

The decision in one line: Adopt, pinned to ^3.3, gated on the Nova 5 upgrade, starting with a single price field in staging — because the alternative is either a worse operator experience on native Nova or a day of custom field work we'd own forever anyway.