- How do I add Laravel Form Request validation to a Filament resource form?
- Install the package with Composer (occ-therapist/form-request-validation-for-filament) and let package discovery register it. In your Resource form schema, call ->formRequest(StorePostRequest::class) after ->components() so the Form Request's rules, messages, and attributes map onto the matching fields. An optional getFormRequestValidated() helper trait is available if you need the validated data during the form lifecycle.
- Which Laravel, PHP, and Filament versions does this package support?
- It requires PHP 8.2+, Laravel 12 or 13, and Filament 4.x or 5.x, with a single package handling both Filament majors via an internal adapter layer. Laravel 11 support was explicitly dropped, so older estates cannot adopt it. Check your composer constraints before adding it to an existing application.
- Can I use a Form Request to validate Filament table filters?
- Yes, table filters are a supported context through ->filtersFormRequest(). Filament's deferred filter state paths are normalized so the Form Request rules map onto the filter inputs. The same naming-discipline caveat applies: your Form Request keys must line up with the filter field names.
- How are Form Request rules mapped to Filament fields?
- Rules map automatically by matching each Form Request key to the Filament field state path, including dot notation and wildcards such as items.*.name. Both array syntax and pipe syntax are supported. Naming discipline matters: keys must align with field names, and ->formRequest() must be called after ->components().
- Can I use different Form Requests for create and edit pages?
- Yes. You can pass a context-aware callback so a Store request is used on create and an Update request on edit, or different classes per page. Rules are re-resolved on every validation run, so conditional and dynamic rules stay current.
- Does the package support prepareForValidation(), authorize(), or withValidator()?
- authorize(), withValidator(), passedValidation(), and failedValidation() are not supported, so authorization should stay in Filament policies. prepareForValidation() is listed as unsupported in the README, yet the v1.3.1 release notes say the support added in v1.3.0 is unchanged. Resolve that contradiction in your installed version before relying on request preparation.
- What happens when Filament field rules and Form Request rules conflict?
- Smart rule merging applies and Form Request rules take precedence on conflicts, which keeps the Form Request as the source of truth. The tradeoff is that merged behavior can differ from the original Filament form, so review any field where both places define rules.
- Do dynamic rules like Rule::unique() and required_if work inside Filament?
- Yes, rules are re-resolved on each validation pass and can read the simulated request's input and route parameters. However, the request is simulated rather than a real HTTP request, so auth, tenant, route-parameter, and record-aware rules may behave differently. Test those cases explicitly in your own suite.
- What happens to Form Request rules that do not match any Filament field?
- Orphan rules do not render inline field errors; instead they surface as a Filament notification. That helps catch naming mismatches, but it can also surprise users when a rule silently fails to map. Watch for those notifications during development and QA.
- Is this package mature enough for production use?
- The architecture is sound as a thin adapter that avoids a new validation DSL, but adoption signals are low: roughly 5 GitHub stars, 0 dependents, a single maintainer, and a short release history. Before standardizing, confirm test coverage and the CI matrix across Filament 4 and 5, pin versions, and add your own mapping tests. Keep a fallback plan of declaring rules directly on fields if the package is abandoned.