Filament Number Input Laravel Package

Product Decisions This Supports

• Dashboard/report trust. Filament table and widget aggregates (SUM(), AVG(), etc.) silently produce wrong totals when values arrive as localized strings — "1.234,56" parsed as 1.234. This package targets that class of defect directly, so it feeds decisions about whether our admin reporting is safe to surface to finance/ops users.
• Build vs. buy for locale-aware numeric input. Parsing localized numbers (decimal comma, thousands separators, non-breaking/narrow no-break spaces) is a small but genuinely fiddly problem with a long tail of edge cases. Adopting a focused package is usually cheaper than owning a bespoke cast/mutator.
• Internationalization roadmap. Relevant if we're expanding into EMEA, LATAM, or any market where users type 1.234,56 rather than 1,234.56. It informs sequencing: do we ship locale-tolerant input before or after we ship the panels to those users?
• Use cases to evaluate against. Money and quantity columns in admin panels; CSV/spreadsheet imports carrying local-format numbers; any screen where row values and column totals must reconcile.
• Input-strategy decisions. Informs the choice between strict input masking (prevent bad strings) and tolerant parsing (accept and normalize). These are different product postures with different UX costs.
• Scope boundary. It addresses numeric parsing for Filament specifically — not currency formatting, rounding policy, or display conventions. Those remain separate decisions.

When to Consider This Package

Consider adoption when all or most of the following hold:

• You run Filament v3, v4, or v5 panels — the package is explicitly scoped to those versions, so version compatibility should be confirmed against your actual install.
• Users enter numbers in more than one locale, or a meaningful share of your users use decimal-comma conventions.
• You have observed, or reasonably expect, aggregate mismatches (table summaries disagreeing with row values) or cast/type errors from localized number strings.
• You want the fix at the Filament layer rather than rewriting model casts or adding input masks across every form.
• Your team is small enough that maintaining locale parsing in-house is unattractive.

Look elsewhere when:

• You are not on Filament — this is framework-specific and won't generalize to other UI stacks.
• You are single-locale with strict numeric input — the added surface area buys you nothing.
• You need end-to-end i18n (currency symbols, rounding rules, display formatting). That's a broader formatting concern, not this package's job.
• You prefer storage-layer normalization via casts/mutators only; adding a presentation-layer dependency may be the wrong seam.
• Maturity risk matters more than convenience. At 1.0.x, verify test coverage, issue responsiveness, and upgrade path before putting it under business-critical reporting.

How to Pitch It (Stakeholders)

For executives: This is a small, narrowly scoped dependency that closes a trust gap in our admin reporting. When users type numbers in local formats, totals can come out wrong — which quietly undermines confidence in everything on the dashboard. The package is cheap, reversible, and confined to Filament panels rather than our data model.

For engineering: A drop-in for Filament v3/v4/v5 that encapsulates locale-aware numeric parsing, so we don't hand-roll casts and separators handling in every table and widget. It reduces bespoke code around aggregate paths where the subtle bugs live.

Important caveat to state plainly: release 1.0.2 is a metadata-only change — it sharpens the Packagist description to name Filament v3/v4/v5 and the problem it solves ("no more broken SUM()s or cast errors from localized number strings"). There are no functional, API, or behavioral changes in this release. It improves discoverability and clarifies scope; it does not change the risk profile. Validate the package against its source and test suite before committing, and pin the version given pre-2.0 maturity.