Decimal Input Laravel Package

Technical Evaluation

Package under evaluation: francescobruno-cmv/decimal-input 0.0.1 (MIT). A lightweight, Laravel-native component for decimal-aware form inputs — configurable precision, dot/comma locale parsing, Laravel validation and old() input integration, native step/min/max attributes, and Blade-friendly markup. Release notes for 0.0.1 contain only an auto-generated changelog link; there is no feature manifest, compatibility matrix, or test evidence in the published material. This is a baseline, evidence-thin assessment — treat conclusions as provisional pending the verification items in Key questions.

Architecture fit

• The problem is real and recurring: locale-aware decimal separators (, vs .), monetary and quantity entry, and the string-to-fixed-precision boundary between form input and persistence (DECIMAL(p,s) columns or integer minor units).
• The surface is narrow and idiomatic — a Blade component, a validation rule, and request normalisation helpers. Narrow surface is a virtue: it limits blast radius and keeps the package out of the domain layer's critical path.
• Architecturally this is a convenience dependency, not load-bearing infrastructure. It should be explicitly positioned as such so it can be replaced by ~100 lines of in-house Blade + validation code if maintenance lapses.
• At 0.0.1 this is a single-author package with the API still in flux. Do not let it become the canonical money type across the domain.

Integration feasibility

• Installation is trivial (composer require, service-provider auto-discovery). The real cost is deciding where normalisation lives — request layer, cast layer, or both — and enforcing that convention in review.
• Feasibility is high if the package pairs a validation rule with normalisation helpers. It is materially lower if it ships only UI components, since correctness would then be coupled to Blade templates and API/console input paths would remain unguarded.
• No published PHP/Laravel constraints, CI badge, or test matrix are visible in the supplied material. This is the single largest feasibility unknown and blocks any adoption decision.

Technical risk

• Immature version. 0.0.x carries no semver stability guarantee; expect breaking changes on any minor bump. Exact pinning is mandatory.
• Bus-factor / abandonment. No release narrative, governance, support policy, or visible issue/PR activity. Abandonment is a plausible outcome for a 0-star package.
• Correctness risk in exactly the area that matters. Decimal parsing is a classic source of silent rounding errors, float coercion, and locale ambiguity. Bugs here corrupt financial or inventory data rather than throwing. The package must carry its own test suite before it touches money.
• Supply-chain exposure. A low-adoption dependency in every consuming app widens the audit surface with little community scrutiny to offset it.
• Silent validation laxity. If ambiguous input such as 1,234 is accepted, downstream columns may truncate or coerce without error.
• Frontend coupling. If the Blade component bundles JS assets, an unrelated frontend pipeline upgrade can break input rendering — an availability risk disproportionate to the value delivered.

Key questions

1. What are the declared php and illuminate/* constraints, and which Laravel versions are actually exercised in CI?
2. Does the package ship a validation rule, a cast, a Blade component, or all three — and does it separate input normalisation from output formatting?
3. How are values represented internally — string, BcMath\Number, integer minor units, or native float? Float would be disqualifying for monetary use.
4. Are there tests, and what is coverage on separator handling, thousands separators, negatives, precision overflow, and empty input?
5. How does it behave on invalid input — throw, return null, or silently coerce?
6. Does it require a JS asset build, and what is its accessibility posture?
7. Is there a documented upgrade policy between 0.0.x releases, and who is the named maintainer?

Integration Approach

Stack fit

• Fits any Laravel 9/10/11 application that accepts human numeric input: pricing admin, invoicing, inventory quantities, expense entry, CSV import.
• Best positioned as a presentation / input-boundary utility. Authoritative arithmetic should stay in integer minor units or a decimal library (brick/math, bcmath); this package should only translate at the edge.
• Poor fit where decimals arrive exclusively from machine clients via typed JSON — added risk, no benefit.

Migration path

• No migration is implied: there is no prior version and no legacy API to unwind. Adoption is purely additive.
• Greenfield: adopt early in one bounded surface (a single form and its validation rule), not estate-wide.
• Brownfield: introduce behind the existing validation layer so removal is a one-line revert. Do not retrofit existing persisted data or rewrite working money handling to route through this package — the payoff does not justify the regression risk at 0.0.1.

Compatibility

• Unverified and blocking. Required checks: PHP constraint vs. runtime, Laravel constraint vs. framework minor, conflicts with existing validation/casting packages, and whether a JS asset pipeline is required (a frontend build dependency materially changes integration cost).
• Locale compatibility must be proven, not assumed: an app serving de-DE and en-US users must not reinterpret the same string differently on each side.

Sequencing

1. Spike (1–2 days). Read the source, run the test suite, confirm the internal numeric representation. Stop immediately if values are held as floats.
2. Pin and isolate. Add at an exact version behind a thin internal adapter (your own DecimalInput facade or contract) so the dependency is swappable.
3. Single-surface pilot. One form, one validation rule, one feature flag. Include adversarial test cases: "1.234,56", "1,234.56", "1 234,56", ".5", "1e3", "-0", empty string, non-breaking spaces.
4. Verify the persistence round-trip. Assert that the value written to DECIMAL(p,s) equals the value read back and re-rendered — this catches precision loss a unit suite can miss.
5. Decide on expansion. Widen only after 2–4 weeks of clean operation and positive evidence of maintainer responsiveness.
6. Pre-agree the fallback. Document the ~100-line internal replacement before the pilot merges.

Operational Impact

Maintenance

• Low code footprint, non-zero ownership cost: exact version pinning, Composer audit monitoring, and a standing commitment to re-test on each Laravel major.
• Because release notes are empty, release triage currently requires diffing the repository manually. Budget for that or assign a named owner to repo notifications.
• Unowned 0.0.x dependencies are how "temporary" packages become permanent liabilities. Assign one named maintainer at adoption time.

Support

• No visible support channel, SLA, or security disclosure process. Internal support falls entirely on your team.
• Mitigation: keep the adapter thin enough that one engineer can reimplement it from source in under a day. This is the primary risk-control mechanism and should be treated as a hard design constraint, not a nice-to-have.

Scaling

• Runtime cost is negligible — string parsing on request handling, once per submission.
• The scaling concern is organisational: each additional consuming app multiplies the upgrade surface. At 3+ apps, promote the adapter to a shared internal package so the external dependency is versioned in exactly one place.
• Bulk import is the load-sensitive path. If used inside a CSV importer, benchmark a 100k-row file — per-row object allocation at that volume is measurable.

Failure modes

• Silent precision loss — float coercion or truncation on write. Highest severity, no exception raised; detectable only by round-trip assertions.
• Locale flip — a comma-decimal user's "1,50" read as 150. Requires explicit multi-locale tests, not documentation.
• Validation bypass — a form guarded by the rule while an API endpoint or console command writes the same column unguarded. Enforce normalisation at a shared boundary, not per controller.
• Abandonment or breaking bump — 0.0.2 changes the public API. Mitigated by exact pinning plus the adapter.
• Asset/build regression — if a frontend component is bundled, an unrelated frontend upgrade can break input rendering. Avoid or isolate the UI layer at this maturity.
• Composer resolution conflict — package constraints collide with another dependency's illuminate/* range. Surfaces at install time; low impact, easy to detect.

Ramp-up

• Developer effort: roughly half a day for an experienced Laravel engineer to learn the API, plus the 1–2 day spike. Low.
• The genuine ramp-up cost is organisational discipline: establishing and enforcing the convention "all human-entered decimals pass through this boundary." That is a process change, not a training cost, and it is where most adoptions quietly fail.
• Documentation burden sits with you, not the package: write a short internal note covering where the boundary lives, supported locales, and tested Laravel versions.

Recommendation: Adopt only for a single-surface pilot, at an exact pinned version, behind an internal adapter, in a non-critical-path form. Do not route monetary or regulated data through it at 0.0.1 until the internal representation is confirmed non-float, a test suite is verified, and release hygiene improves. Re-evaluate at 0.1.0 or on evidence of active maintenance.