Nova Slider Field Laravel Package

Product Decisions This Supports

• Feature scoping for continuous-value ranges. v0.1.1 replaces integer-only min/max/interval handling with float support. Any roadmap item whose bounds are fractional — price tiers, weight/shipping bands, dosage or quantity steppers, percentage sliders, time intervals, distance/geo bounds, measurement filters — moves from "needs custom work" to "configuration." Previously these required rounding, scaling by 100, or a hand-rolled shim; that workaround is now avoidable.
• Build vs. buy. The capability surface is narrow (bounds + step). Buying is justified only where the same range definition is consumed in more than one place — e.g. shared by validation rules, an admin-configured settings screen, and front-end slider/stepper metadata. If a single form needs a min and max, native Laravel validation is cheaper and carries no dependency.
• Centralized configuration as a product asset. If the range primitive is a first-class model in your domain (tenant-configurable limits, plan-based quotas, regional thresholds), a shared package reduces divergence between the API contract and the UI. Float support widens that reuse to non-integer domains without a parallel integer-only path.
• Use cases to evaluate now rather than later: coupon/discount thresholds, tax or commission brackets, budget and savings-goal sliders, inventory reorder points with fractional units, SLA/duration intervals.
• Risk-adjusted roadmap input. This is a 0.x release. Feature value is real but modest; treat it as a convenience, not a platform bet, and expect further churn before a stable API. Do not build a differentiated product capability on an unstable major version without pinning.
• Assessment caveat: this evaluation is derived from the v0.1.1 release note alone (no package data, prior assessment, or source review was available). Treat the specifics as provisional and confirm the API surface before committing it to a roadmap.

When to Consider This Package

Consider it when:

• The same numeric range (min/max/step) must stay consistent across validation, persistence, and presentation, and you want one definition rather than three.
• Your domain genuinely needs fractional bounds or steps, so the int→float relaxation removes a real blocker rather than a hypothetical one.
• Your team is already on Laravel and the cost of a small, replaceable dependency is acceptable relative to writing and maintaining the equivalent.
• Your usage is tolerant of pre-1.0 semantics: you can pin a version, read the changelog on upgrade, and absorb occasional breaking changes.

Look elsewhere when:

• You only ever need integer ranges — the added float capability buys you nothing, and a Laravel validation rule plus a config array is sufficient.
• Money is involved. Floats are the wrong primitive for currency. Even with float support in the package, store monetary amounts as integer minor units or a decimal type and keep this package out of the money path; float boundary comparisons will eventually produce off-by-a-cent defects.
• You require API stability guarantees, long-term support, or a security-review trail that a 0.x package cannot provide.
• Range handling is a one-liner in your codebase; the dependency costs more in upgrade attention than it saves.
• You need locale-aware or high-precision decimal arithmetic, unit conversion, or rounding modes — this change adds float types, not decimal semantics.

How to Pitch It (Stakeholders)

For executives (one paragraph): This is a small, low-cost Laravel dependency that handles configurable numeric ranges. The new release lifts an integer-only restriction, which removes a workaround we would otherwise build and lets us ship features with fractional values — pricing bands, filters, steppers — using configuration instead of custom code. The risk profile is low: the package is small, replaceable, and this release is backward compatible for existing integer usage. The one caveat is that it is pre-1.0, so we pin the version and review changes on upgrade rather than assuming stability. Recommendation: adopt for internal tooling and configuration-driven features; keep it out of the money-handling path, where decimal precision is required.

For engineering: v0.1.1 changes min/max/interval from integer to float. Existing integer callers continue to work through normal numeric coercion, so no migration is expected — but confirm behavior under strict_types and any typed constructor/property signatures before upgrading. Two things to watch: (1) float equality at range boundaries, which needs epsilon-aware tests rather than ===; and (2) whether validation messages, error strings, or serialized output now emit 1.0 instead of 1, which can break snapshot tests or API contracts. Add tests covering fractional bounds, boundary inclusivity, and step alignment from a non-zero start before rollout, and pin the version in composer.json.