rtk-query-codegen-openapi: Null values not always respected #3814
Comments
|
I believe this is handled by the upstream https://github.com/oazapfts/oazapfts library |
|
Thanks, I've opened an issue there! It'd be nice to support at least the basics of 3.1.0 since it's been out for a few years now. |
|
@markerikson it looks like the upstream version has been updated to include this fix. Does the package version need to be bumped in RTK? |
|
@mattoni we can bump the version on our side, but assuming it's a minor release upstream, there's technically nothing we need to do here for people to take advantage of it. You can always regenerate your own lockfile if needed to pick up the latest version of a transitive dependency. |
|
@markerikson Unfortunately there's a major update involved because the fix has only been applied to current
I will try to figure out what's missing to make the generator work with the new version. My first impression was that the only thing missing completely in their exports was the |
|
@SimonEggert sorry, clarify what new version of Looking at https://github.com/oazapfts/oazapfts/releases , I do see that they're working on betas for a v6 major, but I'm not clear what relates to this issue specifically. |
|
@markerikson Seems that there's a lot going on in that repo indeed 😉 The release that has the fix is 5.1.7 which is a patch release in itself, but RTK is still using 4.8.0. In order to upgrade and include the bugfix we would need to adapt some breaking changes. |
|
FTR: I opened another issue in the upstream library asking about what the proper way for updating would look like: oazapfts/oazapfts#577 |
|
@markerikson I opened PR #4198 including the necessary |
|
@markerikson is there anything blocking the above from being merged? Would be great for us to be on the latest so we can support 3.1.0 versioned specs. |
I've recently upgraded my OpenAPI schema to 3.1, and while in most places the
style seems to generate the correct code, in other places it does not.
For example, given this:
The generated output is:
Where
stackis not also nullable.The same thing happens in various other spots, such as here in the password field of this nested object:
The output being:
It appears to generate correctly in circumstances such as this:
Where I use an anyOf to reference another type that can also be null in this field, the generated being:
It appears that the generator doesn't work correctly when you have a type with multiple values, and one of them is
null. I think the codegen should support this since it is the recommended way to handle nullable values in the OpenAPI spec.The text was updated successfully, but these errors were encountered: