switch from cebe/php-openapi back to devizzent fork

[MarkusJLechner]

Human Disclaimer: This was research from Claude addressing issues and warnings we see in PHPUnit runs. I couldn't have written the statements any better, so I'm passing them on here 1:1. Seeing how unreliably active cebe has been with the foundation that other packages depend on, I'd recommend using the fork as a dependency again.

Summary

Since v3.0.1 (936f0d1, closing #208), Spectator requires cebe/php-openapi ^1.8 again.
The stated reason was that cebe 1.8.0 added symfony/yaml ^7 support, making the
devizzent/cebe-php-openapi fork unnecessary. That was true at the time — but the
ecosystem has since moved to Symfony 8, and upstream cebe has not followed:

• cebe/php-openapi 1.8.0 (2025-05-07) is still the latest release; master is
  unchanged since the same day. It caps symfony/yaml at ^7.0.
• On a Symfony 8 project, installing Spectator therefore downgrades the
  production symfony/yaml from v8 to v7.4 — a dev-only testing tool silently
  pulling a runtime dependency down a major version.
• On PHP 8.5, cebe 1.8.0 also emits 8 Implicitly marking parameter ... as nullable is deprecated notices per spec parse (SpecBaseObject, Paths, PathItem, Responses,
  Reference, SpecObjectInterface). These become fatal in PHP 9. Fixes exist upstream
  (Fixes PHP 8.4 deprecation warnings cebe/php-openapi#217, #256, since Nov 22, 2024(!)) but haven't been merged or released.

The maintained fork devizzent/cebe-php-openapi (1.1.5) fixes both: it allows
symfony/yaml ^3.4 || ... || ^8 and has the explicit nullable signatures.
league/openapi-psr7-validator (the other big consumer, 0.24) already depends on
the fork — Spectator v3.0.0 did too.

Ask

Would you consider re-evaluating the devizzent/cebe-php-openapi fork, as v3.0.0
used and as league does? Or, as a lighter variant, widening the constraint to

"cebe/php-openapi": "^1.7"

so either parser can satisfy it — ^1.7 still covers the real 1.8.0, and since
the fork declares replace: {"cebe/php-openapi": "1.7.0"}, it would satisfy the
requirement too, letting Symfony 8 / PHP 8.5 projects opt into it while everyone
else keeps resolving upstream cebe.

Either way it looks like no code change would be needed: Spectator only uses
classes that exist identically in both packages —

cebe\openapi\Reader
cebe\openapi\spec\{OpenApi, Operation, PathItem, Response, Schema}
cebe\openapi\exceptions\{IOException, TypeErrorException, UnresolvableReferenceException}
cebe\openapi\json\InvalidJsonPointerSyntaxException

— none of the 1.8-only additions (SecurityRequirements, RawSpecDataInterface)
are referenced.

For context: we currently pin "hotmeteor/spectator": "3.0.0" to get the fork
transitively, and would love to get back onto ^3.0.

[hotmeteor]

Resolved in #225, shipped as v3.0.3.

Went with the lighter variant you proposed — the constraint is now "cebe/php-openapi": "^1.7", so:

• Projects that don't care keep resolving upstream cebe/php-openapi 1.8.0 as before.
• Projects on Symfony 8 / PHP 8.5 can add devizzent/cebe-php-openapi to their own require — its replace: {cebe/php-openapi: 1.7.0} satisfies Spectator's requirement, brings symfony/yaml ^8 back, and picks up the explicit-nullable fixes.

Also added PHP 8.5 to the CI matrix — full 8.3/8.4/8.5 × Laravel 12/13 grid is green. Thanks for the very well-researched writeup.