Laravel Ruleset Validation Laravel Package

Product Decisions This Supports

• Feature Development: Enables rapid implementation of domain-driven validation (e.g., DTOs, domain objects) by decoupling validation logic from controllers or FormRequest classes. Ideal for complex workflows like multi-step forms, API payload validation, or business rule enforcement (e.g., "A user with role X must validate Y").
• Roadmap Prioritization: Justifies investment in validation-heavy features (e.g., admin panels, compliance workflows, or user onboarding) by reducing technical debt. Prioritize features where reusable rulesets can cut 40–60% of validation boilerplate.
• Build vs. Buy: Avoids custom validation frameworks when Laravel’s ecosystem (e.g., FormRequest, Validator) is sufficient. Buy this package if you need scenarios, object-backed validation, or reduced coupling between rules and request handlers.
• Use Cases:
  • Dynamic Validation: Apply rules conditionally (e.g., "Validate phone only if country is US").
  • API Consistency: Standardize validation across frontend (Inertia.js) and backend services.
  • Legacy Systems: Retrofit validation to existing Laravel apps without rewriting core logic.
  • Testing: Isolate validation logic for unit tests (e.g., mock Ruleset dependencies).
  • Scenarios: Validate the same object differently (e.g., CreatePostRuleset::SCENARIO_DRAFT vs. SCENARIO_PUBLISHED).

When to Consider This Package

• Adopt when:
  • Your team writes repetitive or nested validation (e.g., >3 Rule:: chains per endpoint).
  • You need to share validation across controllers/forms (e.g., user profiles, orders).
  • Validation depends on dynamic conditions (e.g., user roles, external APIs).
  • You’re using FormRequest but want to reduce coupling between rules and request handlers.
  • Your project uses DTOs or domain objects that require validation (e.g., CreateUserCommand).
• Look elsewhere if:
  • Validation needs are simple (e.g., basic forms with required|email).
  • You’re using a dedicated validation library (e.g., Spatie’s Laravel Validation) that already meets needs.
  • Your team lacks Laravel/PHP expertise to maintain custom rulesets.
  • You prioritize performance-critical paths (benchmark first—this adds minimal overhead).
  • Your project uses a non-Laravel framework (e.g., Symfony, Django).

How to Pitch It (Stakeholders)

For Executives: "This package lets us build validation logic once and reuse it everywhere—like a ‘validation Lego set’ for our app. For example, if we’re launching a new subscription flow, we can define rules for plan tiers, payment methods, and user eligibility in one Ruleset class, then apply them to web forms, APIs, and admin dashboards. This cuts development time by 30–50% for validation-heavy features and reduces bugs from inconsistent rules. It’s MIT-licensed, integrates with our Laravel stack, and future-proofs our codebase for new workflows."

For Engineering: *"Laravel-ruleset-validation lets you move validation out of controllers into reusable Ruleset classes. Key wins:

• DRY Validation: Define rules once (e.g., Rule::when('is_admin', fn() => Rule::exists('permissions'))) and reuse across FormRequest, DTOs, or controllers.
• Testability: Isolate rulesets for unit tests (e.g., mock User models or external APIs).
• Flexibility:
  • Object-backed validation: Validate DTOs/domain objects (e.g., CreatePostData).
  • Scenarios: Switch rules dynamically (e.g., useScenario('draft') vs. useScenario('published')).
  • Subset validation: Validate only ['title', 'slug'] with $ruleset->only(['title', 'slug'])->validate().
• Future-Proof: Works with Laravel’s validation pipeline (e.g., authorize(), messages(), validated()).
• Zero Boilerplate: No FormRequest subclasses needed for simple cases—just type-hint the Ruleset in your controller.

Example:

// Define once
class CreatePostRuleset extends Ruleset {
    public function rules() {
        return ['title' => ['required'], 'body' => ['nullable']];
    }
}

// Reuse everywhere
$postData = new CreatePostData(title: 'Hello', body: 'World');
$validated = $postData->ruleset->validate(); // Validates DTO

// Or in a controller
public function store(CreatePostRuleset $ruleset) {
    $validated = $ruleset->validate(); // Validates request
}

Trade-offs:

• Learning Curve: Requires adopting a new pattern (but pays off for complex validation).
• Overhead: Minimal (~5–10% slower than raw Validator calls, but negligible for most apps). Recommendation: Pilot this for one validation-heavy feature (e.g., user onboarding) to measure impact before rolling out broadly."*