GeezerVison is showing github.com — OpenAPI 3.1 support? · Issue #373 · oapi-codegen/oapi-codegen
OpenAPI 3.1 support? #373DescriptionOpenAPI 3.1 is great, brings full JSON Schema compatibility. It would be great if generator would support it. Reacted by Ian Wahbe, Ernie Hershey, Essam Youssef, Jared Weinfurtner, Chris Cerk, Felix Edelmann, Chris Dessonville, Yashu Mittal, James Pozdena, Aleksey Bogomolov and 37 more Reacted by Mike Helsel, Daniel Loader, Essam Youssef, Chris Cerk, Chris Dessonville, James Pozdena, Alexis Goodfellow, GreyXor, Brahim Boukoufallah, Victor Elkjær Birk and 3 more Reacted by Vyacheslav Gorbov, Wanderson Silva, dnitsch, Andrei Gadiukov, Bjørn Wiegell, Anthony Bishopric, MURAMATSU Ryunosuke, Matthew Lynch, Sylvain Muller, Albert Cui and 73 more Reacted by Dominik Roos, Amarjeet Singh Rai, Konstantin Burykin, John, Marco Jaeho Cho, Todd Binger, Delaney, Michal Nicpon, crunk1, Claudio Beatrice and 59 more Activityeli-kaplan commented on Sep 2, 2021 Bumping this, OAS 3.1 was released approximately seven months ago now and brings a number of very useful features. Reacted by Vilen Topchii, Alex Pavlov, Michal Jurečko, Ernie Hershey, Essam Youssef, hmmh-dominik-saeume and Ángel Cervera Claudio sonu27 commented on Sep 14, 2021 jamietanna commented on May 12, 2022 Reacted by Wesley Beary and Nikolay Yurin jamietanna commented on Aug 4, 2022 jamietanna commented on Oct 19, 2022 amery commented on Oct 26, 2022 If you end up redesigning oapi-codegen using libopenapi, could you please consider allowing generating code for other languages too? I'm sure people here would be interested in using the same awesome tool to generate non-go client code jamietanna commented on Jun 1, 2023 Just to cover this, there's some discussion between @deepmap-marcinr and I about this, and we're considering - for now - to convert an OpenAPI 3.1 spec to an OpenAPI 3.0 spec (via libopenapi) to continue to rely on kin-openapi, which will allow for OpenAPI 3.1 specs to continue to work, but without some of the benefits.
We'd prefer to keep on kin-openapi for the meantime, but also if there's no expected update to 3.1 (and folks do really want 3.1) we can look at shifting to use libopenapi, but it'll require a slightly more significant set of changes than we're willing to do right now, especially as Marcin is continuing to think about what a v2 could look like jamietanna commented on Jun 2, 2023 For folks looking for OpenAPI 3.1 support, what features are you hoping for? We are looking at what initial changes may be required (supporting multiple types in a schema), but then wondering what additional things could be added to the backlog, like webhook support Reacted by Kei Son and shonigbaum mgabeler-lee-6rs commented on Jul 7, 2023
For folks looking for OpenAPI 3.1 support, what features are you hoping for?
For my team's use cases, you nailed the two key items on the head -- type as an array, and webhooks, in that order of importance.
The type array could definitely be translated to an OAS 3.0 spec pretty easily, by converting it to a oneOf or anyOf, though nullability has some minor challenges in some cases. wjkoh commented on Feb 28, 2024 The fully implemented version of OpenAPI 3.1 can be found at https://github.com/pb33f/libopenapi, while kin-openapi is still in the process of implementing it. Would switching to the former accelerate the support for OAS 3.1? Reacted by Alejandro Mery, Kei Son and Olivier Nguyen Quoc Reacted by ilyong jamietanna commented on Feb 28, 2024 So using libopenapi is proposed in #1388 and is a good option to support OpenAPI 3.1.
It's not something I want us to switch over to as-is, as it's a significant breaking change for folks (for those using this as a library, and some behaviour changes may occur) so would assume this would be a side-by-side thing for some time before maybe switching over.
Additionally, we also need to make sure the middleware used by the project is also https://github.com/pb33f/libopenapi-validator/ instead of using kin-openapi (as they'll differ in what's supported)
I'd welcome folks trying out #1388 with their repos, making sure that it works correctly with your services, etc, and we'll hopefully get it merged before long, but I want to make sure that we set ourselves up for it well due to i.e. needing to make sure that updates to internal code for generating templates also applies to the libopenapi side of things.
It's very much something I want to get done, just also trying to balance it with several other Open Source projects I maintain (all in my free time) as well as trying to keep on top of the incoming issues and PRs! Reacted by Woojong Koh, Alejandro Mery, SimonAM, Pablo Crivella, Seán Murphy, Gyllsdorff, Alexandre Mahdhaoui, Rick Staa, Ilyes512, Steve Coffman and 7 more mromaszewicz commented on Apr 25, 2026 OpenAPI 3.1 support is working in the branch feat/kin-openapi-3.1. All backend routers are supported, but we can't merge this for a while (see the commits and description in the above PR for more info)
This code will not pass CI until we use a Go 1.26 linter and limit CI to go 1.26, as this version of kin-openapi requires go 1.26
However, for those interested, feel free to experiment. Reacted by Артемий, Anton Shchurov, Sean Chittenden, Conrad Parker, Daniel Furman and Ramsay Reacted by Markus Maga, Anton Shchurov, Sean Chittenden, Conrad Parker, Daniel Furman, Geert-Johan Riemer, Adrien Brignon and Fernando Oleo Blanco mromaszewicz commented on May 1, 2026 kin-openapi has backed off their Go requirement, and now we need to bump to 1.25. That's already out for review, and feat/kin-openapi-3.1 has been updated as well. Reacted by Andrew Wray, Ruben Das, ln-12, Daniel Furman, Geert-Johan Riemer, Omar El Halabi, Silvan Kohler, packet-sent, Andrey, Matthias and 8 more Stanzilla commented on May 18, 2026
kin-openapi has backed off their Go requirement, and now we need to bump to 1.25. That's already out for review, and feat/kin-openapi-3.1 has been updated as well.
I just tried your branch it fails on on nullable object schema (type: [object,'null']) mromaszewicz commented on May 18, 2026
kin-openapi has backed off their Go requirement, and now we need to bump to 1.25. That's already out for review, and feat/kin-openapi-3.1 has been updated as well.
I just tried your branch it fails on on nullable object schema (type: [object,'null'])
Thanks for pointing that out. I had unit tests covering various cases, but I missed [object, 'null'] for unspecified objects. The issue stems from the Schema.Is(...) function returning "false" for an object. It's a strict comparison. I'll have it fixed shortly, with additional tests. I found five places in the code which could have problems due to this behavior which I misread. mromaszewicz commented on May 19, 2026 @Stanzilla , please try the latest commit.
Also, henceforth, since people are checking this branch out, I will merge main into here, versus rebasing on top of main. cristiadu commented on Jun 17, 2026 Any news on when this would be able to be released? mromaszewicz commented on Jun 17, 2026 I'm going to make another pass at new bugs in the next few days, and decide then. This branch has some problems around nullable types. All the places that I compute a type has to be aware of both the 3.1 and 3.0 description, and I'm not sure if I covered all the bases yet. Reacted by Ramsay, Cristiano Faustino, hmmh-dominik-saeume, Geert-Johan Riemer, andoks and Timo Järventausta Reacted by Cristiano Faustino, hmmh-dominik-saeume, Phil Sturgeon, Geert-Johan Riemer, Ramsay and andoks
MetadataMetadataDevelopmentNo branches or pull requestsIssue actions
|