Laravel Validation Laravel Package

Getting Started

1. Install and pin. composer require somosyampi/laravel-validation — note the package name and repo name differ (laravel-validation vs laravel-validator), so confirm the actual Packagist name from composer.json before adding it. Pin an exact version ("somosyampi/laravel-validation": "1.0.0" or a commit hash) since the last release was March 2024.
2. Skip the docs, read the source. With no published documentation and zero dependents, src/ is the spec. Open composer.json first (Laravel version constraints, autoload namespace, any extra.laravel.providers), then the service provider, then the validator service class itself.
3. Read the tests before the classes. For a small, undocumented package the test suite is the only reliable usage reference — it shows the constructor signature, whether rules are passed as arrays or methods, and what exceptions are thrown.
4. First use case: validating payloads outside an HTTP request — queued jobs, Artisan commands, importers, webhook handlers, or a service layer shared by an API and a Blade controller — where a FormRequest isn't reachable. That is the gap a "validation service" fills; if you only ever validate in controllers, native FormRequest already covers you and this package adds little.

Implementation Patterns

• Thin FormRequest, fat service. Keep the FormRequest for HTTP concerns (authorize, redirect, JSON negotiation) and have rules() delegate to the service so the same rule set is reused by jobs and commands. Do not duplicate rule arrays in two places — that is the failure mode this package is meant to prevent.
• Context-based rule sets. Model store vs update (and draft vs publish) as separate rule methods or named rule-set keys, and use sometimes/required/Rule::unique()->ignore() inside them. Pass the model or ID into the service rather than branching inside the rule array.
• Validate → DTO. Call the service, then hydrate a DTO from validated() only. Never read $request->all() after validation, or you reintroduce mass-assignment risk.
• Custom rules live in the provider. Register Validator::extend(...) / Rule objects in your own AppServiceProvider or a dedicated one; treat the package as a wrapper around Laravel's validator, not a replacement. Composition with Validator::make() remains available.
• Single entry point. One validateOrFail(array $data, string $context) style method used by HTTP, queue, and console callers keeps error shapes and messages consistent across the app.
• Test the rules, not the package. Feed arrays of valid/invalid payloads into the service in your own unit tests ($this->expectException(ValidationException::class)), so a future major release breakage is caught by your suite rather than in production.
• Livewire / API resources. Expose the same rule set through rules() on Livewire components and reuse the DTO for JsonResource output so validation and serialization never drift.

Gotchas and Tips

• Adoption risk is the headline. 0 stars, 0 dependents, score 0.1. Treat it as vendored code: pin the version, read the diff on every bump, and avoid putting it on a critical path (auth, payments) without it being forked into your own namespace. A fork under App\Support costs a day and removes the bus-factor risk entirely.
• Laravel version drift. Last release 2024-03-19; check composer.json constraints against your Laravel version (11/12) before committing. If it only supports ^10, expect deprecation noise from Validator contract changes and test the upgrade path early.
• Exception handling differs by caller. A FormRequest throws a ValidationException Laravel converts to a redirect or 422 JSON automatically; a service called from a job or command throws the raw exception. Catch it in your job/command and log $e->errors(); for API controllers ensure Accept: application/json or a handler entry so clients get 422, not 500.
• Don't validate twice. If a FormRequest validates and the service validates again, you get duplicated messages and wasted queries (unique rules hitting the DB twice). Pick one boundary.
• Messages and i18n. Check whether the package ships lang/ files or a publishable config (php artisan vendor:publish --provider=...). If not, attribute names come from attributes() in your own classes — set them once or error messages will read like column names.
• Nested and wildcard data. items.*.sku style rules must be spelled out explicitly; a service wrapper rarely infers them, and validated() will silently drop keys with no rule.
• Debugging. The service likely returns a boolean or throws — you won't have $validator->errors() on hand. Catch ValidationException and inspect errors(), or temporarily call Validator::make() directly with the same rules to see the full failure set.
• Extension points to prefer: custom Rule objects, a publishable config for message overrides, and the service provider binding (subclass or interface-bind) — these let you fix or extend behavior locally without patching vendor code.