Validation Laravel Package

Technical Evaluation

Architecture Fit

• Strengths:

  • Fluent API: Chainable validators (v::numericVal()->positive()->between(1, 255)) align well with Laravel’s expressive syntax (e.g., Eloquent queries, Blade directives).
  • Result-Based Validation: ResultQuery objects enable granular error handling, useful for API responses (e.g., JSON:API-style error formatting).
  • Attribute Validation: PHP 8+ attributes integrate seamlessly with Laravel’s dependency injection and model validation (e.g., replacing manual validate() calls in DTOs).
  • ShortCircuit Validation: Optimizes performance for dependent checks (e.g., validating nested forms where later fields depend on earlier inputs).
  • PSR-11 Container: Compatible with Laravel’s service container, enabling dynamic validator registration (e.g., per-tenant validation rules).

• Weaknesses:

  • Breaking Changes (v3.0): Requires PHP 8.5+ and significant refactoring (e.g., validate() → validate() returning ResultQuery). Laravel’s default PHP version (8.2+) may lag behind.
  • Lack of Laravel-Specific Integrations: No built-in support for Laravel’s FormRequest, Validator facade, or ValidatesWhen traits.
  • Error Message Customization: Symfony Translation integration exists but may require additional setup for Laravel’s translation system.

Integration Feasibility

• Laravel Ecosystem Synergy:
  • Form Requests: Can replace FormRequest::rules() with fluent validation (e.g., v::email()->notBlank()->assert($request->all())).
  • Model Validation: Attribute validation (#[Validators\Email]) mirrors Laravel’s #[Rule] (Spatie) but with more flexibility.
  • API Responses: ResultQuery maps cleanly to Laravel’s Validator::failed() or custom JSON responses.
• Migration Path:
  • Incremental Adoption: Start with simple validators (e.g., v::email() in controllers) before replacing FormRequest or Validator facade.
  • Hybrid Approach: Use alongside Laravel’s validator (e.g., Validator::extend() with custom Respect\Validation logic).
• Compatibility Risks:
  • PHP 8.5 Requirement: Laravel 11+ (PHP 8.3+) may need a custom fork or wait for upstream support.
  • Namespace Conflicts: Respect\Validation vs. Illuminate\Validation could lead to IDE/autoloading issues if not namespaced carefully.

Technical Risk

• High:
  • Major Version Adoption: v3.0’s breaking changes may introduce bugs if not thoroughly tested (e.g., validate() → ResultQuery transitions).
  • Performance Overhead: Dynamic factories (v::factory()) or complex compositions (v::shortCircuit()) could impact Laravel’s request lifecycle.
  • Error Handling: Unified ValidationException may require rewriting existing exception handlers (e.g., in API middleware).
• Mitigation:
  • Testing: Validate against Laravel’s test suite (e.g., phpunit + Pest) for edge cases (e.g., nested arrays, recursive validation).
  • Feature Flags: Use Laravel’s config() to toggle between Respect\Validation and native validator.
  • Documentation: Create internal runbooks for common patterns (e.g., "How to migrate FormRequest to Respect\Validation").

Key Questions

1. PHP Version Alignment:

   • Can Laravel’s roadmap support PHP 8.5+ by the time Respect\Validation v3.0 stabilizes?
   • If not, should we fork and backport critical fixes?

2. Validation Layer Strategy:

   • Replace all Laravel validation (e.g., FormRequest, Validator facade) or use Respect\Validation for specific use cases (e.g., complex DTOs)?

3. Error Handling:

   • How will ResultQuery integrate with Laravel’s Validator::errors() or API exception handlers?
   • Example: Convert ResultQuery to Illuminate\Validation\ValidationException.

4. Performance:

   • Benchmark Respect\Validation vs. Laravel’s validator for high-traffic endpoints (e.g., API rate limits).

5. Maintenance:

   • Who will triage Respect\Validation issues (e.g., bug fixes, PHP 8.6 compatibility)?
   • Plan for long-term support if the project becomes inactive.

Integration Approach

Stack Fit

• Laravel Core:
  • Form Requests: Replace rules() with fluent validation in authorize() or custom methods.

    // Before: FormRequest::rules()
    public function rules(): array {
        return ['email' => 'required|email'];
    }
    // After: Respect\Validation
    public function validate(array $data): void {
        v::email()->required()->assert($data['email']);
    }
    

  • Model Validation: Use attributes for DTOs or replace Illuminate\Validation\Rules with Respect\Validation validators.

    class UserDto {
        #[Validators\Email] public string $email;
        #[Validators\Between(18, 120)] public int $age;
    }
    

  • API Responses: Leverage ResultQuery to build structured error responses.

    $result = v::allOf(
        v::key('name', v::notBlank()),
        v::key('email', v::email())
    )->validate($request->all());
    
    if ($result->hasFailed()) {
        return response()->json([
            'errors' => $result->getFullMessage()
        ], 422);
    }
    

• Third-Party Packages:
  • Spatie Laravel-Permission: Replace Rule classes with Respect\Validation validators.
  • Laravel Nova: Customize validation in tooling without modifying core logic.

Migration Path

1. Phase 1: Pilot Projects

   • Scope: Start with non-critical features (e.g., admin panels, internal tools).
   • Implementation:
     • Replace simple FormRequest rules with Respect\Validation.
     • Use ResultQuery for API responses in a single module.
   • Tools: Write a Validator facade wrapper to abstract differences:

     // app/Providers/AppServiceProvider.php
     Validator::extend('respect', function ($attribute, $value, $parameters, $validator) {
         $result = v::email()->assert($value);
         if ($result->hasFailed()) {
             $validator->errors()->add($attribute, $result->getFullMessage());
         }
         return !$result->hasFailed();
     });
     

2. Phase 2: Core Integration

   • Scope: Migrate FormRequest and model validation.
   • Implementation:
     • Create a RespectValidator service to bridge Respect\Validation and Laravel’s Validator.
     • Replace Illuminate\Validation\Rules with Respect\Validation in DTOs.
   • Testing: Validate against Laravel’s test suite for regressions (e.g., nested validation, custom rules).

3. Phase 3: Full Replacement

   • Scope: Deprecate Laravel’s native validator in favor of Respect\Validation.
   • Implementation:
     • Publish a custom Validator facade that delegates to Respect\Validation.
     • Update documentation and onboarding guides.

Compatibility

• Laravel-Specific Gaps:
  • Custom Rules: Respect\Validation lacks Laravel’s Rule objects. Workaround: Create adapters or use v::satisfies().
  • Presence/Absence: Laravel’s unique:table,column requires custom integration (e.g., database checks before Respect\Validation).
  • Conditional Rules: ValidatesWhen trait needs a custom implementation using v::shortCircuit().
• Workarounds:
  • Database Validation: Use Laravel’s Validator::extend() for DB checks, then pass to Respect\Validation.
  • Conditional Logic: Implement ValidatesWhen via v::factory():

    v::factory(fn($data) => $data['active'] ? v::email() : v::nullable())
        ->assert($data);
    

Sequencing

1. Pre-Migration:
   • Audit all validation logic (e.g., FormRequest, Validator facade, custom rules).
   • Identify high-risk areas (e.g., complex nested validation, custom exception handling).
2. Pilot:
   • Choose a module with minimal user impact (e.g., internal dashboard).
   • Test error handling, performance, and edge cases.
3. Core Migration:
   • Replace FormRequest rules incrementally (e.g., 1 request per sprint).
   • Update model validation (e.g., DTOs, API resources).
4. Post-Migration:
   • Deprecate old validator usage via Laravel’s deprecated() helper.
   • Monitor error rates and