Getting Started

On Laravel 11 (PHP 8.2+), require the L11-compatible patch: composer require vendor/package:^2.9.2. If you are pinned to ^2.9.0 or ^2.9.1, bump the constraint or run composer update vendor/package --with-dependencies and confirm with composer show.
Look first at the README’s installation/usage section, then composer.json for illuminate/validation and illuminate/support constraints, then the package service provider for bindings. If the package publishes config, publish it and read the defaults before overriding.
First use case: add the package’s rule(s) to a FormRequest or an inline Validator::make() call, then cover it with a feature/unit test. Because 2.9.2 is a compatibility release, start by running your existing validation tests on Laravel 11 before changing application code—there is no new API to learn.

Implementation Patterns

CI matrix: test Laravel 10 and 11 (illuminate/*: ^10.0|^11.0) and keep PHP 8.2+ in the matrix. Use composer why-not vendor/package 2.9.2 when dependency resolution fails.
FormRequest integration: keep package rules in rules() alongside Laravel’s built-ins and prefer Rule:: objects for conditional logic. If the package exposes rule objects, use them instead of string rules for easier unit testing.
Custom rules/extensions: register package extensions in a service provider’s boot(); otherwise use Laravel’s ValidationRule contract or Validator::extend(). Namespace extension names to avoid collisions.
Self-validating models (if the package provides a trait): define rules/messages on the model, let validation run on save, and catch ValidationException at the controller/job boundary. Use saveQuietly() only when intentionally bypassing validation.
Testing: unit-test with Validator::make($data, $rules)->passes() and assert errors()->all(); feature-test the endpoint to confirm 422/redirect behavior and message keys. Add at least one L11-specific CI job if you depend on framework validation behavior.
Config/deploy: keep only overrides in the published config and run php artisan config:clear/config:cache during deploy so L11 environments do not serve stale settings.

Version constraint trap: ^2.9.0 may resolve to a patch that lacks L11 metadata. Pin ^2.9.2 or verify the installed version after updating.
Laravel 11 baseline: PHP 8.2 is required, and deprecated validator behaviors are not automatically available. Audit any package code calling removed/deprecated Validator methods.
Provider order: if the package binds a custom validator or extends the Validator facade, register it after Laravel’s validation provider; otherwise your extension can be overwritten.
Messages/locales: custom rule messages often break when locale files are cached. For L11 skeleton apps, run php artisan lang:publish and verify validation.php contains your keys.
Debugging: inspect Validator::make(...)->errors()->toArray() and $validator->failed() to see which rule failed; for model validation, log $exception->errors() before rethrowing. In tests, use assertInvalid() / assertSessionHasErrors().
Extension points: prefer Laravel’s ValidationRule contract and Rule:: objects over string-based Validator::extend() for new code—they are easier to test and less sensitive to provider boot order. Wrap package-specific rule factories behind app-level rules to isolate future upgrades.