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 for OpenAPI overlays #125

Open
TristanSpeakEasy opened this issue Jun 8, 2023 · 6 comments
Open

Add support for OpenAPI overlays #125

TristanSpeakEasy opened this issue Jun 8, 2023 · 6 comments
Labels
enhancement New feature or request

Comments

@TristanSpeakEasy
Copy link
Contributor

Would love to see support for https://github.com/OAI/Overlay-Specification/blob/main/versions/1.0.0.md

@daveshanley
Copy link
Member

Good suggestion! adding to the backlog.

@daveshanley daveshanley added the enhancement New feature or request label Jun 13, 2023
@daveshanley
Copy link
Member

I've been thinking more about this. I've looked into the syntax, and it's kinda crazy.

Is there much support for Overlays? I don't see much of it myself.

I think there are better ways to cover the use cases that overlays would provide when adding, removing or modifyingm or creating 'sub renders'

@jamietanna
Copy link

jamietanna commented Aug 15, 2024

I think there are better ways to cover the use cases that overlays would provide when adding, removing or modifyingm or creating 'sub renders'

What would you be thinking? 👀

oapi-codegen/oapi-codegen#1553 is where we're considering this, as a common issue folks have is that they can't modify the source spec before generation, or it's a pain to modify it from the upstream, and as upstream spec changes, they have to re-apply patches

From what I can tell, https://github.com/speakeasy-api/speakeasy/tree/main/internal/overlay is Speakeasy's implementation (which we'd consider vendoring into oapi-codegen)

@TristanSpeakEasy
Copy link
Contributor Author

Just to add to this we are seeing a huge amount of usage of overlays these days as most customers do want to keep their spec pure because they are generating it from code.

It would definitely be great to see support in Libopenapi though as that would give us hopefully relevant line numbers to either the spec or overlay when validation fails for example.

Though as Jamie mentions we do have our own implementation as a preprocess before passing over to Libopenapi.

@jamietanna let us know if there would be interest from you for us to open source our implementation

@jamietanna
Copy link

Thanks @TristanSpeakEasy! Looking at it, there is actually https://github.com/speakeasy-api/openapi-overlay which may do the heavy lifting? 👀

@TristanSpeakEasy
Copy link
Contributor Author

TristanSpeakEasy commented Aug 16, 2024 via email

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

No branches or pull requests

3 participants