Laravel Ruleset Validation Laravel Package

Technical Evaluation

Architecture Fit

• Modular Validation: Aligns perfectly with Laravel’s existing validation ecosystem (e.g., FormRequest, Validator facade) while introducing a declarative, reusable ruleset pattern. Reduces coupling between validation logic and controllers/forms.
• Domain-Driven Design (DDD) Support: Enables object-backed validation (e.g., DTOs, domain objects) alongside traditional request validation, making it ideal for clean architecture or hexagonal applications.
• Scenario-Based Rules: Lightweight context switching (e.g., draft vs. published validation) via scenarios avoids bloated rules() methods with conditional logic.
• Laravel Compatibility: Mirrors FormRequest behavior (e.g., authorize(), messages(), validated()), so teams familiar with Laravel validation can adopt this with minimal learning.

Integration Feasibility

• Zero Configuration: Uses Laravel’s auto-discovery, so no service provider or facade setup is required.
• Backward Compatibility: Works alongside existing FormRequest classes—no forced migration. Rulesets can coexist with traditional validation.
• Dependency Injection: Rulesets can be type-hinted in controllers (like FormRequest), enabling seamless integration into existing routing.
• Validation Pipeline: Supports Precognition, error bags, and custom messages, ensuring parity with Laravel’s validation system.

Technical Risk

Key Questions

1. Validation Scope:
   • Will this replace all FormRequest classes, or only complex ones? (Avoid over-engineering simple forms.)
2. Dynamic Rules:
   • Do you need async validation (e.g., checking external APIs)? The package supports it but may require custom Rule objects.
3. Testing Strategy:
   • How will you test rulesets? (Recommend: unit tests for rules + feature tests for integration.)
4. Team Adoption:
   • Is the team comfortable with declarative validation (vs. imperative Validator::make())?
5. Legacy Code:
   • How will existing FormRequest classes migrate to rulesets? (Incremental refactor recommended.)
6. Custom Rules:
   • Do you need custom validation rules? The package integrates with Laravel’s Rule objects seamlessly.
7. Error Handling:
   • Will you use the throwing (validate()) or non-throwing (fails()) validation flow? Document team preference.

Integration Approach

Stack Fit

• Laravel-Centric: Optimized for Laravel 10/11, leveraging:
  • Dependency Injection (rulesets as controller parameters).
  • Service Container (auto-resolution of rulesets).
  • Validation Pipeline (supports all FormRequest features).
• PHP 8.1+: Requires attributes (#[Ruleset]) and named arguments, so ensure your stack supports it.
• Complementary Packages:
  • API Tools: Works with Laravel Sanctum, Laravel Passport, or Spatie API Resources.
  • Form Handling: Pairs well with Livewire, Inertia.js, or Filament for frontend validation.
  • Testing: Integrates with Pest or PHPUnit for validation testing.

Migration Path

Example Migration:

// Before: FormRequest
class StoreUserRequest extends FormRequest {
    public function rules() {
        return [
            'email' => ['required', 'email'],
            'password' => ['required', 'min:8'],
        ];
    }
}

// After: Ruleset + Controller
class StoreUserRuleset extends Ruleset {
    public function rules() {
        return [
            'email' => ['required', 'email'],
            'password' => ['required', 'min:8'],
        ];
    }
}

class UserController {
    public function store(StoreUserRuleset $ruleset) {
        $validated = $ruleset->validate();
        // ...
    }
}

Compatibility

• Laravel Versions: Tested on Laravel 10/11; check Packagist for supported versions.
• PHP Versions: Requires PHP 8.1+ (for attributes and named args).
• IDE Support: Works with PHPStorm, VSCode, and Laravel IDE Helper for autocompletion.
• Database/ORM: No direct dependency, but rulesets can validate Eloquent models or DTOs.

Sequencing

1. Start with DTOs: Validate domain objects (e.g., CreateUserCommand) before touching FormRequest classes.
2. Replace Complex Requests: Target endpoints with nested rules, conditional validation, or shared logic.
3. Introduce Scenarios: Use scenarios for context-specific validation (e.g., admin vs. user flows).
4. Deprecate Old Patterns: Gradually phase out FormRequest classes in favor of rulesets.
5. Document: Add internal docs on when to use rulesets vs. FormRequest.

Operational Impact

Maintenance

• Pros:
  • Centralized Rules: Changes to validation logic (e.g., "email must be verified") require one update across all rulesets.
  • Reduced Duplication: No more copy-pasting rules() arrays.
  • Easier Debugging: Rulesets are isolated and can be tested independently.
• Cons:
  • New Abstraction Layer: Teams must learn ruleset lifecycle (e.g., validationData(), scenarios).
  • Tooling Gaps: Limited IDE support for scenario-based rules (may need custom snippets).
• Best Practices:
  • Naming Conventions: Use *Ruleset suffix (e.g., UserProfileRuleset).
  • Rule Organization: Group related rulesets in App\Rulesets namespace.
  • Versioning: Treat rulesets like domain logic—version alongside feature branches.

Support

• Proactive Measures:
  • Runbooks: Document common validation errors (e.g., "Why is my required rule failing?").
  • Debugging: Use dd($ruleset->getValidator()->errors()) for troubleshooting.
  • Community: Leverage Craft CMS (package maintainer) for edge cases.
• Common Issues:
  • Scenario Misconfiguration: Ensure useScenario() is called before validate().
  • Data Mapping: Verify validationData() returns the correct array structure.
  • Caching: Rulesets are not cached by default; avoid performance pitfalls in loops.

Scaling

• Performance:
  • Validation Overhead: Negligible for most use cases (Laravel’s Validator is optimized).
  • Large Payloads: For bulk validation (e.g., 1000+ records), consider batch processing or async rules.
  • Benchmark: Test with laravel-debugbar to monitor Validator execution time.
• Team Growth:
  • Onboarding: New devs can reuse rulesets without understanding original validation logic.
  • Ownership: Assign ruleset stewards for critical domains (e.g., payments, users).
• Horizontal Scaling:
  • Stateless rulesets work well in queued jobs or microservices.
  • For distributed validation, consider shared validation libraries (