Getting Started

Confirm PHP 8.3 before anything else. Since v1.1.2 the package genuinely requires PHP 8.3 — OptionValidationService uses typed class constants, which are a parse error on 8.2 ("Cannot parse"). Check php -v locally and in CI before running composer require; on 8.2 the failure surfaces at autoload time, not at install time, so it looks like a broken package rather than a version mismatch.

Install and publish:

composer require <vendor>/<package>:^1.1
php artisan vendor:publish --tag=<package>-config

Look first at OptionValidationService. It is the entry point that carries the validation logic and is the file referenced by the release notes, so it is the best map of what the package actually does: which option keys it knows about, which rules it applies, and how it reports errors.
First use case: validating a user-supplied "options" payload — product variants, plan add-ons, integration settings — instead of hand-rolling a 200-line rules() array in a FormRequest. Resolve the service and pass the payload through it, then assert $service->passes() / read $service->errors().

Implementation Patterns

Wrap it in a FormRequest. Resolve OptionValidationService from the container in rules() or prepareForValidation(), and let Laravel's validation pipeline own the response shape. This keeps your controllers thin and makes the errors consistent with the rest of the app.
Config-driven rule sets. Publish the config and define option groups there rather than in PHP code, so product/ops changes don't need a deploy of application logic. Cache-bust with php artisan config:cache in your deploy script.
Service-layer usage for non-HTTP paths. Console commands, imports, and queued jobs should call the service directly rather than reusing the FormRequest — validation rules and HTTP concerns stay separated.
Dependency injection over facades. Type-hint the service (or its interface) in constructors so tests can swap a fake; this also makes the PHP 8.3 requirement a single, obvious place to bump when you upgrade the framework.
Test the boundaries. Write feature tests for valid payloads, one test per rule failure, and a test asserting the exact error keys — error key naming is the most common source of front-end breakage when wiring errors into a Vue/Inertia form.
Version pin deliberately. Use ^1.1 (not *) in composer.json; the 8.3 floor was a hard cutover, and a loose constraint plus an older runner image is how a green build turns red on a Friday.

PHP 8.2 is a silent trap until runtime. Typed class constants don't exist before 8.3, so the class file fails to parse rather than throwing a friendly exception. Align composer.json require.php, CI matrix, Docker base image, and local Herd/Valet in one change.
This patch is a compatibility/documentation fix, not a behaviour change. If you are already on 8.3 you can take v1.1.2 with no code changes; if you are on 8.2, this release is telling you the previous release was already broken for you — do not treat it as the regression.
Do not silently bump the floor. If your app supports 8.2 for other packages, you now need a polyfill-free split: either upgrade the runtime or pin to the last release that parsed on 8.2 and document the constraint.
Errors are nested. Option validation errors typically key by option path (options.color, options.sizes.0), not flat names — read $validator->errors()->toArray() during debugging before wiring messages to a UI.
Config caching hides rule edits. If new options "don't validate", run php artisan config:clear before hunting in the service.
Extension points to prefer: custom rule objects and the published config block, rather than subclassing OptionValidationService — subclassing is what will hurt when the internal rule list changes in a minor release.