Getting Started

Treat v0.1.1 as a low-risk enhancement: it widens numeric range options (min, max, interval) from integer-only to float-capable. There are no indicated breaking changes or deprecations.
Start by checking the package config and any published configuration keys for min, max, and interval. Confirm whether they are read directly, cast internally, or passed into validation/service classes.
First use case: set fractional boundaries such as min: 0.5, max: 99.9, interval: 0.25, then exercise a feature test that passes a decimal value through the package.
Review the package README/API surface for the exact option names and expected input types. Because this is an early 0.x release, pin the version deliberately and re-run the relevant tests after each update.

Implementation Patterns

Prefer fractional values in config when the domain requires them, for example:
- 'min' => 0.5
- 'max' => 99.9
- 'interval' => 0.25
Keep Laravel validation aligned with the new capability. Use numeric rather than integer for inputs that may be fractional, then apply gte/lte or package-specific validation for boundaries.
Normalize incoming decimal strings from forms/APIs before handing them to the package. If the package expects numeric values, cast explicitly at the boundary: (float) $request->input('value').
Add focused tests for:
- Integer values still accepted.
- Float boundary values accepted.
- Values just below min and just above max rejected.
- Fractional interval alignment, where applicable.
In Form Requests or DTOs, validate and normalize once, then pass a trusted numeric value into the package rather than repeatedly casting in controllers.
For database-backed values, store exact decimals in decimal columns when precision matters. Avoid relying on database float columns for money-like values.
When building factories/seeders, remove hardcoded integer assumptions if they no longer reflect the package’s supported range.
After changing config, run php artisan config:clear in local/dev and ensure deployment config caching is rebuilt.

Float precision is the main pitfall. Avoid strict equality checks like $value === 0.3; use an epsilon or the package’s normalization behavior.
Environment variables arrive as strings. If min, max, or interval are configurable via .env, cast them in config ((float) env(...)) or document that only numeric strings are valid.
Laravel’s integer validation rule will reject valid fractional inputs. Audit any rules that were written before v0.1.1 and relax them to numeric where appropriate.
Check whether the package casts values internally. This release allows floats at the option level, but other code paths may still assume integers.
Guard against zero or negative intervals if the package does not do so. Add application-level validation when interval semantics matter.
Test boundary conditions with decimal values, not just integers, especially around min/max edges and interval alignment.
If debugging unexpected range behavior, dump the resolved config and the normalized value immediately before package invocation; most issues will be string-vs-float or stale config cache.
Because this is a 0.x package, treat the float support as an extension point to verify in your own integration tests rather than assuming full float safety across all features.