Options Resolver Laravel Package

Product Decisions This Supports

• Configuration-integrity work, not product differentiation. This package addresses a recurring failure mode: unvalidated option arrays silently accepting typos, wrong types, or missing keys and failing deep in a request or queue job. That makes it a reliability/quality lever rather than a roadmap feature.
• Build vs. buy for internal package surfaces. If we ship internal Laravel packages, SDK clients, or artisan commands with array-shaped options, the decision is "hand-rolled isset/array_key_exists checks, Symfony OptionsResolver, or this." This package is the lightweight, fluent, type-safe candidate in that comparison.
• Standardizing a validation contract. A single declarative schema per option set gives us one place to review defaults, required keys, allowed values, and nested shapes — useful for code review and for onboarding engineers onto shared packages.
• Use cases worth scoping: service-provider/config block validation; SDK and API-client constructor options; CLI command flags mapped to arrays; action/DTO hydration from request payloads; test-fixture builders that need strict inputs.
• Not supported by this package: end-user validation UX, form requests, authorization, or anything customer-visible. Keep those in Laravel's native validator.
• Adoption signal is the decision input. 0 stars, 0 dependents, and a single maintainer mean this is a source-review-and-vendor decision, not a composer require and move on decision.

When to Consider This Package

Consider it when all of the following hold:

• We maintain multiple internal PHP/Laravel packages that expose array-shaped options, and the same class of misconfiguration bug has recurred more than once.
• The team is on PHP 8.x with typed properties/enums and wants type-safety enforced at the option boundary, not just in docblocks or static analysis.
• We want a small, dependency-free alternative to pulling Symfony's OptionsResolver into a Laravel-only codebase.
• The API surface is narrow enough to wrap behind an internal OptionSchema interface in a day or two, so the dependency is swappable.
• We can accept single-maintainer risk because the blast radius is internal tooling, the license is MIT (forkable), and we pin the version and vendor the source.

Look elsewhere when:

• Symfony OptionsResolver is already the ecosystem default — it is battle-tested, widely depended on, has years of edge-case hardening, and is a safer bet for anything long-lived. Choose it unless bundle size or a hard "no Symfony" constraint is real.
• Laravel's native Validator or config() schema checks already cover the need. Most config validation is a handful of rules; a new dependency is unjustified ceremony.
• Compliance, procurement, or security review applies. With no community, no disclosed CVE process, and no downstream users to surface breakage, the supply-chain story is weak.
• Requirements are trivial. PHPStan/Psalm array shapes plus a few assertions may be sufficient and cost nothing.
• We need proven production behavior. Effectively zero adoption means we are the first real user; budget for reading the source and writing our own tests rather than trusting the README.
• Treat the future-dated release as a flag to verify actual release cadence and changelog discipline before committing; a version bump is not evidence of maintenance.

How to Pitch It (Stakeholders)

For executives: This is a small MIT-licensed PHP utility that turns "we forgot to validate an options array" bugs into explicit, readable schema definitions. It is cheap to trial and cheap to remove. It is not a strategic dependency and it has essentially no adoption, so my recommendation is a time-boxed pilot inside internal tooling only — never on a customer-facing critical path — with the integration isolated behind our own interface so we can drop or replace it without a rewrite. Expected upside is fewer misconfiguration incidents and faster review of package option surfaces; expected cost is a few engineer-days plus ongoing single-maintainer diligence.

For engineering: Fluent, type-safe option schemas with defaults, required keys, and allowed values — the same problem Symfony OptionsResolver solves, minus the Symfony dependency, plus stricter typing. It has zero dependents and one maintainer, so we will read the source, pin the version, and write our own acceptance tests before it lands in anything shared. Wrap it: one internal OptionSchema facade, no direct imports outside that adapter. Success criteria for the pilot: two internal packages migrated, all existing option-validation tests still green, no measurable cold-boot or request-time regression, and a documented one-day path back to Symfony OptionsResolver or native Laravel validation.

Recommendation: Approve a 1–2 sprint spike with the adapter boundary as a hard requirement; defer any broader rollout until the pilot demonstrates maintainer responsiveness and we have a fallback proven.