Validator Laravel Package

Getting Started

Start by installing the package via Composer:

composer require spiral/validator

The core entry point is the Validator class. For a first use case, define a simple validation schema using rule objects (e.g., Required, Email, Length) and validate an associative array:

use Spiral\Validator\Validator;
use Spiral\Validator\Rule as R;

$validator = new Validator();
$input = ['email' => 'invalid'];

$rules = [
    'email' => [new R\Required(), new R\Email()],
];

$errors = $validator->validate($input, $rules);
// $errors contains structured error data if validation fails

Check the src/Rule/ directory and README.md for available built-in rules.

Implementation Patterns

• Rule reuse via ValueObjects or DTOs: Encapsulate validation logic into dedicated validator classes (e.g., UserRequestValidator) with a getRules() method, promoting testability and reuse across handlers/controllers.
• Nested validation: Use Nested or Each rules to validate arrays of structs (e.g., validating a list of order items with their own rules).
• Custom rules: Extend Spiral\Validator\Rule\AbstractRule to implement domain-specific constraints (e.g., UniqueEmail). Override validate() to return false on failure and provide descriptive error messages.
• Integration in Spiral Framework: When used with Spiral, register validators as services and inject them into controllers or actions—use ValidationFilter (if available in the framework bundle) to auto-validate HTTP requests.
• Error formatting: Leverage ErrorBag (returned from validate()) to group errors by field and render them in views or JSON responses using getMessages() or first().

Gotchas and Tips

• ArrayAccess vs. object input: The Validator expects array-like input; if passing objects, use ArrayObject or extract to arrays first. No built-in object hydration—validate flattened arrays.
• Non-nullable fields: A missing key with no Required rule is ignored, not treated as invalid. Always add Required() explicitly for mandatory fields.
• Rule composition order matters: When chaining rules (e.g., new R\Required(), new R\Email()), early failures short-circuit—subsequent rules won’t run. Use separate arrays if all rules must fire (e.g., [new R\Required()], [new R\Email()]).
• Testing tip: Write unit tests for validators in isolation (just test rule logic + inputs). Mock the Validator if used as a dependency in higher-level tests.
• Custom error keys: By default, errors use field names as keys. You can nest and rename keys in your rules or post-process ErrorBag for front-end compatibility.
• Performance: Avoid large rule sets in tight loops; precompile or cache schemas when validating high-throughput payloads.