Support symfony/options-resolver 8 (fixes #290)

[neildaniels]

Summary

Fixes #290. The library crashed on symfony/options-resolver 8 with Cannot use object of type Closure as array in Client.php:216 because v8.0 removed support for defining nested options by passing a Closure to setDefaults() (deprecated in 7.3, removed in 8.0). The closures stayed as raw default values and $options['hydration'] arrived in postResolve() as a Closure.

Changes

Options-resolver fix (composer.json, lib/Tmdb/Client.php):

• Widen the symfony/options-resolver constraint to ^4.4 || ^5 || ^6 || ^7 || ^8.
• Bind the three nested resolvers (http, hydration, event_dispatcher) via OptionsResolver::setOptions() when available (introduced in 7.3), falling back to the legacy closure-as-default pattern on older versions. The original setDefaults([...]) block is preserved almost verbatim — each nested closure is captured into a local via 'key' => $var = function (...) and then re-bound afterwards.

PHPStan baseline updates (phpstan-baseline.neon):

• The method_exists($resolver, 'setOptions') guard is tautological from PHPStan's perspective on a given CI job (always-true when the installed OptionsResolver has the method, always-false otherwise), with different identifiers per outcome. Both outcomes are baselined with reportUnmatched: false so whichever fires per job gets silenced and the other entry sits idle without tripping the unmatched-ignore check.
• Unrelated drift: a php-http/cache-plugin release between Update composer dependencies #289's last-green CI on 4.1 (2026-01-30) and now moved handleRequest() to the new @internal AbstractCachePlugin parent, invalidating the existing argument.type ignore on Psr6CachedRequestListener.php:106 and adding a new method.internalClass error. The repo has no composer.lock, so every CI run pulls the latest cache-plugin — 4.1 would also fail PHPStan on a fresh re-run today. Baseline refreshed accordingly. Long-term fix is to stop calling the internal parent method, tracked separately.

Why a runtime branch instead of bumping the floor

setOptions() only exists from options-resolver 7.3, which requires PHP ≥ 8.2. Bumping the constraint to ^7.3 || ^8 would implicitly force the library to PHP 8.2+, breaking installs on the lib's currently-declared "php": "^7.3 || ^8.0" floor. The method_exists() guard preserves that floor at the cost of the two-entry baseline silencing.

Coverage

The CI matrix in .github/workflows/continuous-integration.yml runs PHP 7.4–8.5 × {normal, low, dev}. With the constraint widened to ^8, jobs on PHP ≥ 8.4 + normal/dev will now install options-resolver 8 and exercise the setOptions() path — the previous matrix passed only because the old constraint excluded v8 entirely, which is how #290 escaped detection. low jobs pin v4.4 and exercise the legacy fallback. All 59 PR checks green.

Reviewer notes

• The reporter's other two items in Does not work in PHP 8.4 and symfony/options-resolver 8 #290 are non-issues: symfony/options-resolver is already in require (composer.json:36), and the PHP 8.4 implicit-nullable deprecation in HttpClient::getOptions was fixed in 5a9ea4c.
• Happy to split the cache-plugin baseline refresh into its own PR if you'd prefer the options-resolver diff isolated — it's bundled here only because CI was unmergeable without it.

Test plan

• CI green across the PHP 7.4–8.5 × {normal, low, dev} matrix
• Manual smoke: instantiate Tmdb\Client on PHP 8.4 with symfony/options-resolver:^8 installed
• Manual smoke: instantiate Tmdb\Client on PHP 7.4 with symfony/options-resolver:4.4 installed (legacy path)

🤖 Generated with Claude Code