Skip to content

Draft: OpenAPI 3.1 - #128

Open
cebe wants to merge 11 commits into
masterfrom
openapi-31
Open

Draft: OpenAPI 3.1#128
cebe wants to merge 11 commits into
masterfrom
openapi-31

Conversation

@cebe

@cebecebe commented Oct 18, 2021

Copy link
Copy Markdown
Owner

This branch will contain all changes made to support OpenAPI 3.1.

I added the following:

  • New method OpenApi::getMajorVersion() to return the current OpenAPI version, this should be used to make version dependent decisions when loading and validating the description.
  • OpenAPI 3.1 schema files for valdiation vai CLI

Possibly incomplete list of TODOs on this one:

This replaces #117.

@cebecebe added this to the 1.6.0 milestone Oct 18, 2021
@Jean85

Copy link
Copy Markdown

This looks great, thank you @cebe!
Can we help in any way? Is there a "TODO" list to complete this?

Comment threadschemas/openapi-v3.1.json
@cebecebe modified the milestones: 1.6.0, 1.7.0Feb 9, 2022
Xerkusand others added 2 commits February 9, 2022 12:31
Signed-off-by: Aleksei Khudiakov <aleksey@xerkus.pro>
* 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
@cebecebe modified the milestones: 1.7.0, 1.8.0Apr 20, 2022
@cebe

cebe commented Apr 20, 2022

Copy link
Copy Markdown
OwnerAuthor

Is there a "TODO" list to complete this?

Added a TODO list to the main comment on this PR. not sure if this is all that needs to be done though.

@colinmollenhour

Copy link
Copy Markdown

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!

@colinmollenhour

Copy link
Copy Markdown

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 unevaluatedProperties option, but this is really just a new feature of JSON Schema. I'm not sure if that needs to be implemented specifically in this library or not, but I would assume it at least needs to be supported by the JSON Schema parser?

@philsturgeon

Copy link
Copy Markdown

If you released a new version with OAS3.1 support and didn't support unevaluatedProperties properties straight away then I doubt anyone would even notice. I wouldn't let that hold you up.

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.

@shulard

Copy link
Copy Markdown

Hello guys !

How can we help here ? Do you need more tests or is this PR miss some code ?

@philsturgeon

Copy link
Copy Markdown

@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.

@WyriHaximus

Copy link
Copy Markdown

@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.

@WyriHaximus

Copy link
Copy Markdown

The 8.2 deprecations pr for OA 3.1: #178

@WyriHaximus

Copy link
Copy Markdown

Also just filed #179 with a small fix for webhooks

@DEVizzent

Copy link
Copy Markdown

@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.
Thank for fixing the deprecations @WyriHaximus

@acelaya

Copy link
Copy Markdown

@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 thephpleague packages, should we consider it now "the official" one? And if so, would you be open to enable issues on your fork? I would like to report something that works when using OAS 3.0 but not OAS 3.1

@DEVizzent

Copy link
Copy Markdown

@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 thephpleague packages, should we consider it now "the official" one? And if so, would you be open to enable issues on your fork? I would like to report something that works when using OAS 3.0 but not OAS 3.1

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.

@acelaya

acelaya commented Jun 16, 2023

Copy link
Copy Markdown

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 😅

image

To enable issues you need to go to https://github.com/DEVizzent/cebe-php-openapi/settings, and check this:

image

@shulard

Copy link
Copy Markdown

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 thephpleague adoption 😄).

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.

@DEVizzent

Copy link
Copy Markdown

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 😅

image

To enable issues you need to go to https://github.com/DEVizzent/cebe-php-openapi/settings, and check this:

image

Sorry I thought it was a default option. Now it's enabled.

@DEVizzent

Copy link
Copy Markdown

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 thephpleague adoption 😄).

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.

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.

Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

10 participants

@cebe@Jean85@colinmollenhour@philsturgeon@shulard@WyriHaximus@DEVizzent@acelaya@Xerkus@marcelthole