Weave Code
Laravel Validation Laravel Package
datalogix/laravel-validation
A Laravel package that extends the built-in validator with reusable custom validation rules and helpers, helping you organize validation logic and apply consistent rules across forms and requests.
Laravel Validation is a package the power of Respect Validation.
Frequently asked questions about Laravel Validation
- What does datalogix/laravel-validation actually do?
- It is a thin adapter that plugs Respect Validation rules into Laravel's validator as native-looking extensions, so you can reference them by name in your rules arrays. Instead of hand-writing Rule objects, you get reusable rules such as hetu, portuguese_nif, public_domain_suffix, between_exclusive, contains_count, mimetype and uploaded. The package registers no middleware, overrides no services and touches no persistence, so it stays a bounded input-validation dependency rather than a platform commitment.
- Which Laravel and PHP versions does the 4.x line support?
- The 4.x line ships as a standard Composer package with service-provider auto-discovery, but the authoritative Laravel and PHP constraints live in its composer.json and release notes, so check those against your target versions before adopting. The v4.0.1 notes are patch-level and do not describe any change to the framework support matrix, so do not assume 4.0.1 widened or narrowed compatibility. If you are on an older Laravel minor, verify the constraint first rather than relying on the package name.
- How do I install datalogix/laravel-validation?
- Install it with composer require datalogix/laravel-validation and let Laravel's package auto-discovery register the service provider, so no manual entry in config/app.php is normally required. Publish the shipped translation stubs with php artisan vendor:publish so the localized messages are available in your application. After that you can use the rule names directly in your validation arrays.
- What validation rules does the package add?
- It registers seven rules built on Respect Validation: hetu for Finnish personal identity codes, portuguese_nif for Portuguese tax IDs, public_domain_suffix for domain inputs checked against public suffix data, between_exclusive for exclusive range checks, contains_count for counting occurrences within a value, plus mimetype and uploaded for file-upload validation. Because they are exposed as ordinary Laravel extensions, they compose with required, nullable, string and the rest of your existing rule chains. Check the per-rule documentation for the exact argument order and placeholder semantics before wiring them into forms.
- How do I use these rules in a Laravel form request?
- Add the rule name to the rules array exactly as you would a built-in rule, for example 'nif' => ['required', 'string', 'portuguese_nif'] inside your FormRequest rules() method or a Validator::make call. The package only extends the validator, so authorization, request lifecycle and error bag behaviour stay entirely Laravel's. Keep the rules scoped to fields that genuinely need the standard being enforced, since adopting every rule by default adds unnecessary surface area.
- How do I customize the validation error messages and which locales ship?
- Messages are standard Laravel translation keys, so you customize them through the published language files or your own overrides rather than through package config. As of v4.0.1 the package ships en and pt_BR strings for all seven rules, which closed a gap where raw keys such as validation.hetu could render directly into user-facing forms. Re-publish or merge the stubs into a branch and diff them against your current published set, since publishing can overwrite files you have already edited. The documented placeholders are :value, :values, :min and :max.
- What changed in v4.0.1 and is it a breaking change from 4.0.0?
- v4.0.1 is a patch on top of 4.0.0: it adds en and pt_BR translation keys for the seven rules, documents the placeholder semantics, and removes a dead attribute message key. That removal is harmless because Laravel's internal validateAttribute() shadows the Respect rule, so the key was never read and there is no behavioural change for existing consumers. Nothing in the release requires application code changes, making it a drop-in composer update from 4.0.0.
- Is upgrading from 3.x to 4.x a breaking change I need to plan for?
- Treat it as a major upgrade rather than a patch: the v4.0.1 notes only cover changes within the 4.x line and do not describe the 3.x to 4.x delta. Review the 4.0 changelog before scoping the work, then upgrade in a non-production branch and run your existing validation test suite. Sequence it as its own change so any behaviour differences are attributable rather than mixed in with a routine dependency bump.
- How do I test these custom validation rules?
- Because the rules are registered as normal Laravel extensions, you can assert them with Validator::make in unit tests or through feature tests against the form requests and API endpoints that use them. Cover both passing and failing payloads for each rule you adopt, and assert the rendered message text rather than just the failure, since raw translation keys leaking into output was the defect fixed in 4.0.1. After any upgrade, re-run the suite and spot-check every adopted rule in the target locale to confirm localized messages still render.
- When should I skip this package and just write my own rule?
- If your forms only need generic checks, Laravel's built-in rules and a custom Rule class cover the case with no extra dependency. This package earns its place when you have a concrete, standards-driven need such as Portuguese NIF for KYC flows, Finnish HETU for identity onboarding, public suffix checks for multi-tenant domain input, or mimetype and uploaded semantics for file handling. The sensible policy is to adopt per rule, not per default, and to confirm the pinned Respect Validation major version and its coupling to rule class names before committing.
Weaver
How can I help you explore Laravel packages today?