Rut Laravel Package

Getting Started

Install the package and try the validation rule first — it is the highest-leverage entry point:

composer require laragear/rut

Then, in a FormRequest, use the rut rule. The package auto-registers it:

public function rules(): array
{
    return [
        'rut' => ['required', 'rut'],
    ];
}

Look first at the Rut facade (or the rut() helper) for one-off normalization, and at RutCast if you store RUTs on Eloquent models. The v5.3.0 addition of static RUTs is the new first-use case worth knowing: you can now get a deterministic, valid RUT for fixtures, seeds and test assertions instead of a random one, and the same value can be reused across test runs.

Implementation Patterns

• Validation in requests and rules. Prefer the rut rule string in FormRequest classes and inline Validator::make() calls. It handles format (with or without dots/dash), the check digit (DV/K) and rejects garbage input.
• Casting on models. Add RutCast (or the alias) to $casts so $model->rut returns a normalized string and rejects invalid values on assignment. Combine with a rut column type of string and an accessor if you need dotted display.
• Normalization before persistence. The package normalizes input to a canonical form. Persist the canonical form and format only at the presentation layer — this avoids duplicate-looking records ('12.345.678-5' vs '12345678-5').
• Static RUTs for testing (v5.3.0+). Use the new static generator in factories, seeders and Pest/PHPUnit data providers so assertions against a fixed RUT don't break between runs. This replaces the old habit of using random generated RUTs in test dummies; the release explicitly removed static RUTs from the validation dummies, so update any fixtures that depended on that.
• Generating dummy data in factories. For fake data use the random generator in fake()/factory context; reserve the static generator for places where you assert on an exact value.
• Rule objects. If you need conditional validation (e.g. only for Chilean customers), compose the rule inside a Rule::when(...) block or a custom rule rather than sprinkling rut across every request.

Gotchas and Tips

• Canonical vs display form. Don't assume the package returns the format you typed. Always re-fetch the normalized value after validation/casting before comparing to a stored column.
• Static RUT semantics in 5.3.0. The static RUT is a fixed, reproducible value — good for tests, bad for anything that needs uniqueness per record. For a unique column, keep using the random generator or a real source. Also check your existing test dummies: static RUTs were removed from validation dummies, so any assertion relying on a hardcoded dummy value should be migrated to the new static generator.
• StyleCI-only changes are a no-op for you. The other PRs in v5.3.0 (StyleCI fixes, PHP version bump for the CI style job) don't affect runtime behavior — no config republish needed.
• Check digit edge cases. DV 'K'/'k' and leading zeros are frequent sources of flaky tests; assert against the normalized output rather than hand-rolled expectations.
• Debugging failed validation. Inspect the normalized value with the facade (Rut::normalize($input) or equivalent helper) before blaming the rule; most "valid RUT is rejected" reports are formatting artifacts such as trailing whitespace or non-breaking spaces pasted from spreadsheets.
• Extension points. Wrap the rut rule in a named custom rule if you need custom messages, or override the validation message in lang/ rather than editing the package. Prefer the facade/cast boundary over touching package internals when you need project-specific normalization.