Skip to content

Support nullable as type arrays for OpenAPI 3.1 #898

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

Closed
timomeh opened this issue Apr 20, 2022 · 2 comments · Fixed by #968
Closed

Support nullable as type arrays for OpenAPI 3.1 #898

timomeh opened this issue Apr 20, 2022 · 2 comments · Fixed by #968
Labels
PRs welcome PRs are welcome to solve this issue!

Comments

@timomeh
Copy link

timomeh commented Apr 20, 2022

In OpenAPI v3.1 nullable: true was removed in favor of type arrays with the value "null". Reference: https://www.openapis.org/blog/2021/02/16/migrating-from-openapi-3-0-to-3-1-0

# OpenAPI v3.0
type: string
nullable: true

# OpenAPI v3.1
type:
- "string"
- "null" 

The current version of openapi-typescript generates those properties as unknown, instead of string | null.

@drwpow
Copy link
Contributor

drwpow commented Apr 24, 2022

I think there are 2 things here worth addressing:

1. This feels like a good change that should happen for both 3.0 and 3.1

I think the unknown behavior is probably improved by a string | null union as you suggested. I think I remember some previous changes to the nullable flag, but I don’t recall an argument against having string | null generated (but if I’m wrong or if someone finds a previous decision in the issues this ticket disagrees with, please remind me!).

2. This library should probably distinguish between 3.0 and 3.1

This doesn’t block the previous solution from happening, but it may be needed in the future.

Extra info

There is an internal version number that gets passed around for the parts of the codegen where Swagger 2.x differs from OpenAPI 3.x. But where OpenAPI 3.0 differs from 3.1, this library could do better.

I think this wouldn’t be a major change—probably just switching that internal version number to a discriminated union (e.g. 2 | 3 | 3.1 or perhaps a string equivalent). That should probably happen at some point.

Sidenote: previous versions of this library did have more of a separation between 2.x and 3.x schemas, but all-in-all they share so much in common that it was easier to maintain one codebase and hard-code in the deviations rather than maintain 2 completely-isolated generators

Anyways, would love if someone could open a PR to address this!

@drwpow drwpow added the PRs welcome PRs are welcome to solve this issue! label Apr 24, 2022
@BrandonGoren
Copy link
Contributor

@drwpow I have a PR open that I think solves this issue by handling array types recursively: #917

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
PRs welcome PRs are welcome to solve this issue!
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants