- What is alt-three/validator?
- It is a small Laravel package that provides an abstract Validator class for moving validation logic out of controllers into reusable, testable service objects. It wraps Laravel's validation factory and adds a hash rule for checking an input against a stored hash, such as a password. The package is deliberately thin: one abstract class plus a package-specific ValidationException.
- How do I install alt-three/validator?
- Install it with Composer using composer require alt-three/validator. There is no config file, facade, or service provider bootstrapping to publish, because the validator is resolved through Laravel's container. The real constraint is dependency resolution: the package's illuminate/* requirements are pinned to the Laravel 5.x and 6.x era, so installation will likely fail on newer Laravel versions.
- Which Laravel versions does alt-three/validator support?
- Its Composer constraints target the Laravel 5.x and 6.x era, and the last release was on 2020-07-25. It is not contemporaneous with Laravel 9, 10, or 11, so expect dependency resolution to fail there. Running it on newer versions means forking and widening the illuminate/* constraints, then retesting.
- How do I use the hash validation rule in Laravel?
- Add the package's hash rule to the rules array for the field you want to check, passing the stored hash the input should match. The rule then verifies the submitted value against that hash, which is useful for password confirmation flows or other hashed-token checks. Because it plugs into Laravel's validation pipeline, it composes with required and other standard rules.
- How do I create a reusable validator with alt-three/validator?
- Extend the package's abstract Validator class and define the rules for the form or request, along with any custom messages and attribute names. Then resolve that class through Laravel's container and call validate() with the input data. Validation failures throw the package's ValidationException, which carries a MessageBag.
- Can I use alt-three/validator on Laravel 10 or 11?
- Not directly. The package's illuminate/* constraints are pinned to older Laravel releases, so Composer will refuse to install it on Laravel 10 or 11 without workarounds such as ignoring platform requirements, which is not recommended. The realistic options are to fork the package and widen the constraints, or replicate the small abstraction internally.
- How does alt-three/validator compare to FormRequest validation?
- FormRequest and $request->validate() keep validation inside Laravel's native HTTP layer and are the default idiom for most applications. alt-three/validator instead treats validation as a service object: you inject the validator, call validate(), and catch its exception. That is easier to unit test and reuse outside controllers, but it adds a second validation pattern if your codebase already uses FormRequests.
- What exception does alt-three/validator throw?
- It throws its own package-specific ValidationException containing a MessageBag, not Illuminate\Validation\ValidationException. That matters because global exception handlers, API error formatters, and Inertia or Livewire adapters often key off the concrete Laravel exception type and will silently miss the package's one. You need to catch it explicitly or map it to Laravel's exception before your error layer sees it.
- Is alt-three/validator still maintained?
- No. The upstream repository is archived, the last release was 2020-07-25, and it has around 20 stars and zero dependents. There is no security response path and no upstream triage, so any defect or incompatibility becomes your responsibility. Adopting it means committing to a fork you own.
- What are the alternatives to alt-three/validator?
- For most teams the simplest alternative is Laravel's native validation via FormRequest or $request->validate(), with a custom rule or Hash::check closure replacing the hash rule. If you like the service-object pattern, inject Illuminate\Contracts\Validation\Factory directly or write a small internal abstract validator plus an exception that extends Laravel's ValidationException. Both avoid the abandoned dependency and keep your error handling working unchanged.