Validate Laravel Package

Getting Started

Install with Composer:

composer require psx/validate

The package has almost no documentation and only a handful of tests, so the fastest onboarding is to read the source directly. Look at, in order:

1. src/Validator.php (and ValidatorInterface) — the entry point you will actually call.
2. src/Filter/ — the catalogue of available filters (e.g. Integer, Float, Boolean, Email, Url, Length, RegExp, Choice/InArray, Callback, DateTime); each file is small and self-describing.
3. src/Error.php / exception classes — how failures are surfaced.
4. tests/ — the only real usage examples.

First use case: validating and coercing a single scalar value, which is what this library is designed for.

use PSX\Validate\Validator;
use PSX\Validate\Filter;

$validator = new Validator();

$result = $validator->validate($_POST['age'] ?? null, new Filter\Integer());

if ($result instanceof \PSX\Validate\Error) {
    // invalid — inspect message
    $message = $result->getMessage();
} else {
    // $result is the filtered/coerced integer
}

The mental model: a filter is a value transformer + constraint. It takes raw input (usually a string from HTTP or a config file) and either returns a clean typed value or an error object. It is not a schema validator and does not understand arrays or objects as a whole.

Implementation Patterns

Wrap it in a Laravel rule. The cleanest day-to-day integration is a custom validation rule so PSX filters live inside Laravel's familiar $request->validate() flow:

class PsxFilter implements \Illuminate\Contracts\Validation\Rule
{
    public function __construct(private \PSX\Validate\Filter\FilterInterface $filter) {}

    public function passes($attribute, $value): bool
    {
        return !(new \PSX\Validate\Validator())->validate($value, $this->filter) instanceof \PSX\Validate\Error;
    }

    public function message(): string
    {
        return 'The :attribute is invalid.';
    }
}

Then: 'email' => ['required', new PsxFilter(new Filter\Email())].

Normalise before you validate. Because filters coerce, run input through them once and use the returned value — don't discard it and keep using the raw string. This is the main reason to prefer PSX filters over Laravel's regex: rules: you get a typed value back, not just a boolean.

Chain filters explicitly. For multi-constraint fields (length + character set, range + integer), apply filters in order in a small helper rather than expecting one filter to do everything:

$value = $this->apply($value, new Filter\Length(1, 255));
$value = $this->apply($value, new Filter\AlphaNum());

Use Callback for domain rules. Where the built-in filters run out (checking against a DB whitelist, currency codes, a country list), the Callback filter is the extension point — keep the closure pure and side-effect free so it stays testable.

Integrate at boundaries, not everywhere. The natural places are: form request validation, import/CSV parsing in Artisan commands, and queue-job payload hydration. Do not sprinkle filters through your domain layer — validate at the edge, then pass typed values inward.

Test the filter, not the framework. Unit tests around each filter call are cheap and give you the documentation the package lacks. A tests/Validation/ folder mirroring your field list pays for itself quickly.

Gotchas and Tips

• Error returns vs. exceptions. validate() returns an Error object on failure rather than throwing or returning false. Always use instanceof checks; a truthiness check on the result is a silent bug (an error object is truthy).
• required and defaults are separate arguments. Optional fields, null handling, and default values are controlled by parameters on the validate call, not by a Required filter. Getting this wrong is the most common source of "null passes validation" surprises.
• Coercion cuts both ways. Filters like Integer/Boolean/Float may cast "abc" or "0" in ways your business logic doesn't expect. Assert the returned value's type in tests rather than assuming the filter only validates.
• It is scalar-oriented. There is no nested-schema traversal. For arrays/objects validate each element in a loop or layer Laravel's validator on top; don't expect a PSX filter to walk a structure.
• Thin docs, one maintainer, ~0 dependents (and outside the PSX stack). Pin the version in composer.json and budget time to read source when behaviour is unclear. Treat the upstream repo as frozen.
• Debugging tip: when a filter rejects unexpectedly, echo get_class($filter) and the raw value before the call — most confusion comes from the value being null or an array when a scalar filter was expected.
• Extension point: implement FilterInterface yourself for reusable domain filters; that is a cleaner long-term move than scattering Callback closures, especially given the low maintenance activity upstream.
• Escape hatch: if the filter catalogue feels limiting versus Laravel's built-in rules, keep PSX for typed coercion at boundaries and use native rules for the bulk of request validation — mixing both in one codebase is fine and often the pragmatic choice.