| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
|
Overall OK for me - would be easier to just say that we generate OpenAPI 3.1 schema here though 🤷 |
Sorry, something went wrong.
|
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? |
Sorry, something went wrong.
|
Wait... OpenAPI 3.1 is still not out yet? :O |
Sorry, something went wrong.
Sorry, something went wrong.
|
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. |
Sorry, something went wrong.
|
🤔 The code is exactly the same on master, isn't it? core/src/JsonSchema/TypeFactory.php Line 172 in eae59df I think it would be merged without conflicts. |
Sorry, something went wrong.
|
The code for the schema yes the code for the open api generation no. |
Sorry, something went wrong.
| Back | FazBrowse Home | New Git URL |
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.