Skip to content
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

Add support to use either swagger 2.0 or openapi 3.0 #137

Closed
raviteja83 opened this issue Apr 2, 2019 · 4 comments
Closed

Add support to use either swagger 2.0 or openapi 3.0 #137

raviteja83 opened this issue Apr 2, 2019 · 4 comments

Comments

@raviteja83
Copy link

raviteja83 commented Apr 2, 2019

Steps to reproduce

Expected behavior

You should allow me to either use openapi 3.0 or swagger in the config.

Actual behavior

Without openapi 3.0 BearerAuth won't be supported. Also if I set swagger to undefined and add openapi 3.0 to the config, I am getting cannot read property get of type undefined error

You can check the Bearer Auth at https://editor.swagger.io/ by editing and converting it into openapi 3 and updating bearerAuth in securitySchemes from the docs

System configuration

Tell us about the applicable parts of your setup.

Module versions (especially the part that's not working):

NodeJS version:
10.x

Operating System:
Ubuntu 16.04

Browser Version:
Latest chrome

React Native Version:

Module Loader:
gulp

@raviteja83 raviteja83 changed the title Add support to use etehr swaggger 2.0 or openauth 3 Add support to use etehr swaggger 2.0 or openapi 3.0 Apr 2, 2019
@raviteja83 raviteja83 changed the title Add support to use etehr swaggger 2.0 or openapi 3.0 Add support to use etehr swagger 2.0 or openapi 3.0 Apr 2, 2019
@raviteja83 raviteja83 changed the title Add support to use etehr swagger 2.0 or openapi 3.0 Add support to use either swagger 2.0 or openapi 3.0 Apr 2, 2019
@Mairu
Copy link
Collaborator

Mairu commented Apr 6, 2019

I am also very interested in this feature. I am also willing to implement this or / and helping to maintain this repository. Are you still in search as stated in some of the still open pull requests. @daffl

@daffl
Copy link
Member

daffl commented Apr 12, 2019

This is still the case. A rewrite might probably be the best approach. I'm happy to help but nobody ever really told me what they need, they usually just fell off the map.

@Mairu
Copy link
Collaborator

Mairu commented Apr 12, 2019

Ok if you also think a rewrite is the best approach I try my luck. I am just not sure if both swagger 2.0 and openapi 3.0 support is needed or if it is sufficient to just support openapi 3. Would make it a lot easier.

@EspadaV8
Copy link
Collaborator

This is something that I had really wanted to spend some time on, alas, we had a major change in our company which caused a restructuring and change in the roadmap, which unfortunately meant that I wasn't able to finish what I was working on.

I had been able to hack in some changes to support OpenAPI 3 without changing too much of the code. A lot of the changes are really just the locations of very similar objects. With the current version there are issues with the output that means it produces invalid Swagger 2 files, some of these have been fixed, but a few remain. It would be nice if the OpenAPI 3 output didn't have this issue.

As for supporting Swagger 2 and OpenAPI 3, I don't think both need to be supported at the same time. I don't see why you would want 2 if it supported 3 (and if you did, you could always use an older version of the package). Once OpenAPI 3 is supported I imagine it would just cause a major jump in the version number (up to 0.8.0) so that existing projects aren't suddenly forced to use OpenAPI 3.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants