Expose validation rules to Blade as $validations (like $errors)

[bunyaminbilenkaratas]

The Problem

Laravel already shares validation results with every Blade view automatically via $errors. But the validation rules themselves are never exposed to the frontend.

This means that for every form, validation rule introspection is either skipped entirely or done manually — independently from the FormRequest. Over time, these two sources drift apart and become inconsistent.

// FormRequest — source of truth
public function rules(): array
{
    return [
        'name'  => 'required|string|min:2|max:100',
        'email' => 'required|email|unique:users',
    ];
}

{{-- Blade — duplicated, manually maintained --}}
<input name="name" required minlength="2" maxlength="100">
<input name="email" required type="email">

There is no built-in mechanism to bridge this gap.

---

The Proposal

Expose the validation rules amenable to introspection from the current FormRequest (or Validator) as a $validations variable in every Blade view, following the same pattern as $errors.

{{-- Attributes only — drop into any existing input --}}
<input name="name" {{ $validations->attr('name') }}>

{{-- Output: <input name="name" required minlength="2" maxlength="100"> --}}

Or, exposed as JSON for JS-driven forms:

<script>
    const rules = @json($validations->toArray());
</script>

---

What Gets Exported, What Doesn't

Not every Laravel validation rule can meaningfully run on the client. The proposal is to export only introspectable rules and silently skip the rest.

Exported:
required, min, max, string, integer, numeric, email, url, digits, digits_between, size, in, not_in, regex, max (on strings), mimetypes (on file inputs), accepted, confirmed

Not exported (server-only):
unique, exists, gt, lt (when referencing other DB fields), custom closure rules, any rule that requires a database query or server-side state.

This distinction is well-defined and finite. It does not need to be open-ended.

---

Why Not Precognition?

Laravel Precognition solves a related but different problem. Precognition provides live validation feedback by sending the current form state to the server on each input change and returning validation results — the same shape as $errors, just earlier.

$validations would export the rules themselves, statically, at page render time. No extra requests. No network dependency. These are two complementary layers:

	Precognition	$validations
What it provides	Validation results (errors)	Validation rules (constraints)
When it runs	On each input change (network request)	At page render (zero extra requests)
Use case	Live server-backed feedback	Native HTML attributes, offline-capable client validation

Both can coexist without conflict.

---

Why This Belongs in Core

$errors is a shared view variable. It is injected automatically by the framework via Illuminate\Foundation\Providers\FormRequestServiceProvider and the ViewErrorBag. It works without any manual wiring in controllers or views.

$validations follows the exact same pattern. It is scoped to the same lifecycle — a FormRequest is already resolved before the response is rendered. The rules are already parsed internally by Illuminate\Validation\Validator. Extracting and sharing them is a small, well-bounded addition to an existing pipeline — not a new system.

This feature depends on the FormRequest resolution lifecycle, which is managed internally by the framework. Implementing it correctly outside of core would require hooking into that lifecycle from the outside — duplicating internal timing assumptions that are not part of any public contract. A package could technically work, but it would be brittle and tightly coupled to internals that may change between releases.

---

Rough Implementation Surface

The change would touch these areas:

• Illuminate\Validation\Validator — add a method to extract introspectable rules into a structured format.
• A new Illuminate\Validation\ValidationRuleSet (or similar) class to hold and query the exported rules, mirroring the interface of ViewErrorBag.
• Illuminate\Foundation\Providers\FormRequestServiceProvider (or the relevant view-sharing middleware) — inject $validations into every view when a FormRequest is in scope, defaulting to an empty ValidationRuleSet otherwise.

---

Open Questions

1. Should $validations be populated only when a FormRequest is used, or also when $request->validate() is called directly in a controller?
2. Should the exported format be opinionated (a Laravel-specific structure), or should it target a standard like HTML5 constraint validation attributes directly?
3. Should there be a Blade directive (e.g. @validations) as a shortcut, similar to how @error wraps $errors?

---

Interested to hear if this aligns with how the team thinks about the validation pipeline, and whether the scope feels right.

[shaedrich]

I can see your point, however, I'm not sure if this is usually wanted. It makes more sense for component frameworks—they would really benefit from this. So, I guess, it comes down to whether Laravel intends to use this for Inertia/Livewire