Validation Rules Laravel Package

Getting Started

1. Install the package:

   composer require twofas/validation-rules
   

2. Check for auto-discovery. Open vendor/twofas/validation-rules/composer.json and look at the extra.laravel.providers block. If a service provider is registered, it will boot automatically; if not, add it manually to config/app.php. Also check for a config/ directory inside the package — if one exists, publish it:

   php artisan vendor:publish --provider="TwoFAS\\ValidationRules\\ValidationRulesServiceProvider"
   

3. Look at src/ first. Most packages of this shape ship one class per rule, each implementing Illuminate\Contracts\Validation\Rule (or the newer ValidationRule on Laravel 10+). The namespace is usually TwoFAS\ValidationRules\Rules\*. Read the class docblocks — they define the expected input shape (phone number, TOTP code, base32 secret, etc.).
4. First use case. Drop a rule into a FormRequest for a 2FA-related field:

   use TwoFAS\ValidationRules\Rules\PhoneNumber;
   
   public function rules(): array
   {
       return [
           'phone' => ['required', 'string', new PhoneNumber()],
       ];
   }
   

   Confirm the exact class name from src/ — the namespace is the one thing you should never guess on a low-traffic package.

Implementation Patterns

• Inline closure vs. rule class. Prefer the package rule over a hand-rolled regex/closure. The whole point of a rules package is that the edge cases (E.164 formatting, leading zeros, Unicode digits, TOTP drift windows) are already handled.
• Compose with native rules. Custom rules typically assume the value is a string and not null. Always pair with required or nullable and usually string:

  'code' => ['required', 'string', 'size:6', new TotpCode()],
  

• Wrap for app-level coupling. If the package namespace might churn, create a thin app-level alias:

  namespace App\Rules;
  class TwoFactorCode extends \TwoFAS\ValidationRules\Rules\TotpCode {}
  

  Now a future swap is a one-file change instead of a grep across form requests.
• Validator facade for tests. Test rules in isolation instead of end-to-end HTTP tests:

  $v = Validator::make(['phone' => '+15551234567'], ['phone' => [new PhoneNumber()]]);
  $this->assertTrue($v->passes());
  

  Add failing cases (empty, whitespace, letters, wrong length) — this is where these rules earn their keep.
• Localization. If the package publishes resources/lang/, override messages per-locale rather than editing vendor files. If it does not, wrap the rule and return your own $fail() message.
• API + web reuse. The same rule instance is safe to reuse across controllers and jobs. Instantiate in rules() or via the container — no state should live on the rule.
• SDK boundary. In a TwoFAS SDK integration, validate at the request boundary and trust the SDK to re-validate. Don't skip the package just because the SDK checks too — you want clean 422s before hitting the network.

Gotchas and Tips

• Zero stars / zero dependents = read the source. Treat this as internal code. Pin the exact version in composer.json ("twofas/validation-rules": "1.2.*") and audit src/ before upgrading. There will be no community answers on Stack Overflow.
• Laravel version drift. The Rule contract was deprecated in favor of ValidationRule around Laravel 10. If the package targets an older Laravel, composer update on your app can silently break it. Check the illuminate/support constraint in the package's composer.json.
• Missing rule on empty values. Many custom rules return true on '' or null because Laravel's implicit validation doesn't apply. Combine with required explicitly — do not assume the rule implies presence.
• Intl / phone parsing dependencies. Rules that validate phone numbers often pull in giggsey/libphonenumber-for-php transitively. If you see Class 'libphonenumber\PhoneNumberUtil' not found, the package's require block missed it — add it yourself and file upstream.
• Regex and Unicode. Rules validating codes or secrets may use /^[A-Z2-7]+$/-style patterns; the u modifier and \A...\z anchors matter. Test with non-ASCII input to confirm behaviour.
• Debugging failures. Temporarily swap in a closure that dump()s the value and returns true/false to confirm the rule is even being invoked — Laravel silently skips rules on missing attributes and on nullable + null.
• Extension points. If the service provider registers Validator::extend() macros (e.g., 'twofas_phone'), use the string form instead of new Rule(). String macros fail loudly with a clear "no such rule" exception, which is easier to debug than a class that never fires.
• Message customization. Most rule classes accept constructor arguments or expose a message() method. If neither exists, subclass and override the $fail message — don't monkey-patch vendor files.