rtk-query-codegen-openapi: Null values not always respected

[mattoni]

I've recently upgraded my OpenAPI schema to 3.1, and while in most places the

type:
    - "object"
    - "null"

style seems to generate the correct code, in other places it does not.

For example, given this:

The generated output is:

Where stack is 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.

[markerikson]

I believe this is handled by the upstream https://github.com/oazapfts/oazapfts library

[mattoni]

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.

[mattoni]

@markerikson it looks like the upstream version has been updated to include this fix. Does the package version need to be bumped in RTK?

[markerikson]

@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.

[SimonEggert]

@markerikson Unfortunately there's a major update involved because the fix has only been applied to current main, so quite some exports of the package have changed or are not available anymore. I think we might need to

1. Reexport things that this repo relies on on oazapft's side
2. Update the imports here to match the new paths

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 ApiGenerator class.

[markerikson]

@SimonEggert sorry, clarify what new version of oazapfts has the fix?

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.

[SimonEggert]

@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.

[SimonEggert]

FTR: I opened another issue in the upstream library asking about what the proper way for updating would look like: https://github.com/oazapfts/oazapfts/issues/577

[SimonEggert]

@markerikson I opened PR #4198 including the necessary oazapfts update if you'd like to take a look.

[mattoni]

@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.