[JSON Schema] Manage correctly nullability

[alanpoulain]

Q	A
Bug fix?	yes
New feature?	no
BC breaks?	no
Deprecations?	no
Tickets	N/A
License	MIT
Doc PR	N/A

Following #3402 and the list of PR from #3807.

In order to validate correctly nullable data against the generated JSON Schema (using assertMatchesResourceItemJsonSchema and assertMatchesResourceCollectionJsonSchema), the schema needs to be compliant with the specification for nullability:

{"type": ["string", "null"]}

However OpenAPI < 3.1 doesn't understand this syntax (OpenAPI 3.1 will at least! https://github.com/OAI/OpenAPI-Specification/releases/tag/3.1.0-rc0) and only understands:

{"type": "string", "nullable": true}

That's why we need a condition when the schema is generated for JSON Schema only.

@Ocramius you may be interested.

[Ocramius]

Overall OK for me - would be easier to just say that we generate OpenAPI 3.1 schema here though 🤷

[alanpoulain]

Not really because we are not in an OpenAPI context here (pure JSON Schema use). However we could also introduce a new key for OpenAPI 3.1, like you suggested in your PR. But maybe when it will be released, don't you think?

[Ocramius]

Wait... OpenAPI 3.1 is still not out yet? :O

[alanpoulain]

Sadly 😢 https://github.com/OAI/OpenAPI-Specification/releases

[soyuka]

Anyways we're going to support only the latest openapi version, by that I mean that we're probably not going to handle multiple open api versions, too hard to maintain.

@alanpoulain you should also try this on master as the OpenAPI code has been refactored there.

[alanpoulain]

🤔 The code is exactly the same on master, isn't it?

core/src/JsonSchema/TypeFactory.php

Line 172 in eae59df

return array_merge($jsonSchema, ['nullable' => true]);

I think it would be merged without conflicts.

[soyuka]

The code for the schema yes the code for the open api generation no.