-
Notifications
You must be signed in to change notification settings - Fork 92
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Draft: OpenAPI 3.1 #128
base: master
Are you sure you want to change the base?
Draft: OpenAPI 3.1 #128
Conversation
Co-authored-by: Cees-Jan Kiewiet <[email protected]>
This looks great, thank you @cebe! |
Add Testcases for OpenAPI 3.1
Add support for WebHooks
Signed-off-by: Aleksei Khudiakov <[email protected]>
* master: (22 commits) Catch recursion when resolving inside included file Improve Responses resolving references Fixes default value for exclusiveMinimum and exclusiveMaximum more specific deprecation add hasPropertyValue() method add comments, optimize tests for #125 During serialization convert empty Map fields to empty Objects Add test to demonstrate OpenAPI v3.0 schema validation fails with empty Path properties yarn upgrade Added docker environment for local development Add symfony 6 support (#151) Bump node-fetch from 2.6.1 to 2.6.7 (#149) Fix CI badge in Readme (#150) Temporarily skip broken test (#145) Run speccy through yarn Add windows and macos cases Temporarily skip broken test Rework CI Run all tests (#136) Drop licence badge from readme (#137) ... Conflicts: README.md composer.json src/SpecBaseObject.php tests/ReaderTest.php
Added a TODO list to the main comment on this PR. not sure if this is all that needs to be done though. |
Has anyone done much testing with this PR? Perhaps if you are using it successfully and share your experiences it will help push it closer to merge time. I'm really looking forward to using this with the PHP League OpenAPI validator! |
Is it actually possible to support OpenAPI 3.1 until the underlying justinrainbow/json-schema library support JSON Schema Draft 2020-12? For example, one new feature of OpenAPI 3.1 not mentioned on #101 is the new |
If you released a new version with OAS3.1 support and didn't support Switching away from hustinrainbow/json-schema might be on the cards. It seems like development has slowed down (jsonrainbow/json-schema#658) and its mostly just in maintenance now. This was suggested as a supposedly drop-in replacement: https://opis.io/json-schema It might be you can just swap packages and get a lot of the way there on the OAS3.1 schema differences. |
Hello guys ! How can we help here ? Do you need more tests or is this PR miss some code ? |
@cebe I completely understand how busy you are, but if you ever want to chat about any of this I would be happy to hop on a Zoom call. Poke me on DMs somewhere and I'll send you a schedule link. No pressure, just want to unblock if I can. |
@cebe Is there a way I can help move this forward? What mainly brought me here today is PHP 8.2 deprecations so I'll look into fixing those on the 3.1 and default branches. Aside from that, I've been using that branch for months now to generate an API client without any issue with a 3.1 spec so far. From my experience, it's pretty stable in its current state. |
The 8.2 deprecations pr for OA 3.1: #178 |
Also just filed #179 with a small fix for webhooks |
@cebe I also was doing some test with this branch and really good results. If you need some help to finish some stuff before merge, I can help. |
@DEVizzent I came across your fork when searching for OAS 3.1 support in this library. Considering it's now even used by one of |
I don't know if official one. But here we didn't find a way to contribute and we need keep evolving the library. So, feel free to create a ticket in the fork and contribute to the project. I will help if I can. |
I would love to, but my point was that issues are disabled there 😅 To enable issues you need to go to https://github.com/DEVizzent/cebe-php-openapi/settings, and check this: |
Maybe someone else already though about it but if @cebe can't maintain this package anymore, based on this MR discussion, it can be interesting to avoid using a personal namespace (a bit too late here because of It might be a requirement to have at least two persons involved in the fork (I don't know @DEVizzent if you already gave access to some other people…) to avoid a blocked situation like this. Same for packagist "distribution channel", if we all decide to move from this current package, no-one can mark it "abandoned" to help user migrate. Not sure it's relevant today but to prevent that kind of situation in the future, having "a team" behind the code seems important. |
Sorry I thought it was a default option. Now it's enabled. |
I agree. WyriHaximus is also a collaborator in the project. And if there are other people who participate on it, I think it's healthy share this permissions. |
This branch will contain all changes made to support OpenAPI 3.1.
I added the following:
OpenApi::getMajorVersion()
to return the current OpenAPI version, this should be used to make version dependent decisions when loading and validating the description.Possibly incomplete list of TODOs on this one:
This replaces #117.