- What does michel/options-resolver do?
- It is a lightweight, framework-agnostic PHP utility that validates and normalizes associative option arrays against a declared schema. You declare required and optional keys, expected types, allowed values, and defaults, and the resolver rejects unknown keys with clear errors when input does not match. It is aimed at constructors, package config objects, job or action payloads, and SDK entry points rather than HTTP request validation.
- Is michel/options-resolver a Laravel package, and which Laravel and PHP versions does it support?
- It is not a Laravel package: it ships no service provider, facade, or publishable config, so you add it as a plain Composer dependency. There is no confirmed compatibility matrix for Laravel 10, 11, or 12, and the PHP version floor is not documented in the material provided. Check the composer.json require block, then add the package to your own CI matrix against the PHP and Laravel versions you actually run before adopting it.
- How do I install michel/options-resolver?
- Install it with Composer, pinning an exact version such as composer require michel/options-resolver:x.y.z, and commit the lockfile. There is no service provider to register and no configuration to publish, so setup is limited to the dependency plus whatever adapter class you write. Before merging, audit the source for global functions or hidden framework assumptions and confirm the Git remote matches the Packagist entry.
- How does michel/options-resolver differ from Symfony OptionsResolver?
- Both validate an associative options array against a declared schema with defaults, required keys, and type checks, so they occupy the same architectural slot. The meaningful differences are in fluent API shape and thrown exception types, which makes migration possible but not a drop-in swap. If you already depend on Symfony components, OptionsResolver has far more production mileage, documentation, and community patching behind it.
- Does michel/options-resolver support nested options?
- The package description advertises nested option support, so structured configuration is in scope rather than only flat scalars. What is not documented is whether nested resolvers are genuinely recursive and whether any recursion-depth protection exists. Spike a nested schema early and lock the behavior down with your own tests before relying on it for deeply structured config.
- Does it reject unknown keys, and is strict mode enabled by default?
- Strict rejection of unknown keys is listed as a core feature, which is the main reason to pick it over hand-rolled array checks. Whether that strictness is on by default or opt-in is not stated in the available material. Feed it a payload with an extra key during your spike to confirm the behavior and decide whether you need a permissive path for forward compatibility.
- Should I use it instead of Laravel's validator or FormRequests?
- No. Laravel's validator and FormRequests remain the right tool for HTTP request input, where you want rules, messages, and error responses integrated with the framework. This package is a boundary-hardening tool for internal array-shaped configuration in constructors, package config objects, and payloads. Do not layer it underneath request validation, because that duplicates checks and complicates error reporting.
- What exceptions does michel/options-resolver throw for invalid options?
- The exception hierarchy is not documented in the material provided, so treat it as unknown until you read the source. Write your own characterization tests for missing required keys, wrong scalar types, nested arrays, and null versus absent values, and assert the concrete exception classes. Those tests also protect you later if you fork the package or swap in a different implementation.
- Is michel/options-resolver safe to use in production?
- Treat the risk as provenance rather than code quality: zero stars, no known dependents, a single maintainer, and no visible CI or coverage evidence. A reported release date that post-dates the evaluation window is a metadata anomaly worth verifying against the upstream commit SHA and repository history. The sensible path is a pilot in one non-critical service, or vendoring a small fork under your own organization.
- How do I avoid lock-in or migrate away from michel/options-resolver later?
- Hide it behind a small internal interface such as App\Support\Options\Schema and keep the package a swappable implementation detail with no facade or service provider. Use it in exactly one bounded context, an internal package config object or a single job payload constructor, instead of fleet-wide. Because the core job is roughly 200 to 400 lines to reimplement, compare indefinite fork maintenance honestly against that cost, with Symfony OptionsResolver as the fallback.