Formatted Number Laravel Package

Product Decisions This Supports

• Build vs. buy — really "adopt vs. write 30 lines." rimu/formatted-number is a single-purpose Laravel Nova field that renders stored numeric attributes with thousands separators, fixed decimals, and currency/percent affixes in index and detail views, leaving the database value untouched. The "buy" side costs no cash but carries real maintenance risk; the honest comparison is "fork-and-own in an hour" versus "write a small custom Number field or a displayUsing() closure using Nova's native options." For a problem this small, those are roughly the same amount of work — and the second has no legacy constraints.
• Internal tooling backlog, not the product roadmap. It matters only if Nova is already your back-office surface. It does not touch customer-facing output, APIs, exports, or business logic, so it should never appear on a customer-facing roadmap — at most it is a line item on an internal DX/admin backlog.
• Presentation consistency across operational dashboards. It supports the decision "should revenue, counts, and quota figures render identically across all Nova resources?" A shared formatting layer reduces one-off displayUsing() closures scattered across resources and the visible inconsistency that follows — staff seeing $1.2M in one place and 1234567.891 in another lose trust in the data.
• Use cases worth scoping: finance/ops resources showing large magnitudes (ARR, cents-stored-as-integers displayed as currency, row counts), read-only reporting resources, and admin screens where raw unformatted numbers undermine confidence in the tool.
• Explicit non-decision: it is not an input mask, a validation layer, or a locale-aware currency formatter. If the question on the table is "how do we accept, validate, and store monetary input," this package does not answer it — and any formatting must stay strictly display-only, enforced structurally (onlyOnIndex() / onlyOnDetail() plus a separate native Number field on forms).
• Documentation-vs-reality caveat for scoping. The package blurb describes a general-purpose, locale-aware PHP formatting library with a fluent API and Blade integration. The actual code is a Nova field with no facade, no service provider, and no publishable config. Any roadmap or estimate built on the description is invalid; treat composer.json and the field class as the only source of truth.

When to Consider This Package

Consider it only when all of the following hold:

• You are already on Laravel Nova (a paid first-party dependency) and the formatting gap is genuinely in Nova resource display.
• You need display-only formatting — the stored value must stay numeric and remain sortable/filterable as-is.
• You are comfortable vendoring or forking: 2 stars, 0 dependents, and a last release of October 2019 means no community, no issue triage, no security response, and almost certainly no compatibility work for Nova 4/5 or modern PHP. Treat the repository as reference source code, not a dependency you install and forget.
• The blast radius of breakage is internal staff seeing an unformatted or misformatted number — not customer data or transactions. That containment is the one genuinely favorable factor.
• Nova's built-in Number field and displayUsing() hooks have been evaluated and do not cover a specific, documented requirement you actually have.

Look elsewhere when:

• You are not on Nova. The entire value is the Nova field contract; nothing is reusable for Blade, Filament, Inertia, or API resources.
• You need i18n or currency semantics. Laravel's Number facade, PHP's NumberFormatter (intl), or moneyphp/money cover locale-aware grouping, currency codes, rounding rules, and minor-unit handling properly. This package does not.
• You are on Nova 4 or 5. The front end is a 2019 compiled bundle built against legacy Vue 2 mixins and Mix asset conventions; it may fail to register or throw in-browser, which breaks create/update forms for staff — not just the one column you wanted to format.
• The requirement is anywhere near a write path, an export, an API payload, or customer-visible output. That is out of scope by design, and stretching the package there converts a contained admin-panel risk into a data-integrity one.
• You need sortable numeric columns. Formatted strings sort lexically, not numerically ($1.2M before $900K), so a formatting field on a sortable header is the wrong tool.

How to Pitch It (Stakeholders)

For executives: This is a tiny, free, unmaintained Nova add-on that makes numbers in our internal admin panels easier to read. It reaches no customers, touches no transactions, and creates no revenue. The real decision is not "should we buy it" — it's "do we want a small piece of first-party display code, or a six-year-old dependency we'd have to own anyway." For roughly the same effort, we can write the equivalent in-house and carry none of the upgrade risk. Recommendation: treat this as a reference implementation, not a dependency.

For engineering: The package is a Nova field plus one compiled Vue component — no service provider, no facade, no config. Its stated value is fully reproduced by ~30 lines extending Nova's Number field with displayUsing(). Because the last release was 2019 and pins Nova 2/3-era constraints, composer require --dry-run is the first step and a resolution failure is the best outcome. If we adopt anything, we vendor the class into app/Nova/Fields/, add PHP tests around grouping/decimals, scope it to onlyOnIndex()/onlyOnDetail(), pair it with a native Number field on forms, verify numeric sorting per resource, and name an owner. The one thing worth building regardless of which field class we use is a central format map (currency/percent/count) so forty resources stop carrying forty inconsistent number_format() closures.

The decision to record: formatting is display-only, it does not apply to exports or API payloads, and the stored value stays numeric and sortable. That boundary — written down and enforced — is the actual deliverable here, not the package.