complex nullable type, change in behavior

[dylbarne]

going from version 3.13.2 to 3.14.0 (and beyond) I am seeing a difference in the generated d.ts file for nullable complex type.

In earlier version, the dtsgen command will produce enumSample?: LengthUom , for new version(s) will generate intersection enumSample?: null & (LengthUom) The latter version causes an issue, since when attempting to use "enumSample" for valid 'Cm' value ts-checking will give error "Type 'string' is not assignable to type 'null'."

I have included simplified json contents that will reproduce behavior: (enum was easiest example to show, but appears to be any class/type reference)

{
  "openapi": "3.0.0",
  "components": {
    "schemas": {
      "TestNullable": {
        "type": "object",
        "properties": {
          "field": { "type": "string", "nullable": true },
          "enumSample": { "nullable": true, "oneOf": [ { "$ref": "#/components/schemas/LengthUom" } ] }
        }
      },
      "LengthUom": {
        "type": "string",
        "x-enumNames": [ "Inch", "Cm" ],
        "enum": [ "Inch", "Cm" ]
      }
    }
  }
}

[horiuchi]

@dylbarne Thank you for your report. 👍

Probably due to the v3.14.0 update. So the type generated when using oneOf has changed. In this case, I think the following change will generate the type as intended.

"enumSample": { "nullable": true, "oneOf": [ { "$ref": "#/components/schemas/LengthUom" } ] }

↓

"enumSample": { "oneOf": [ { "$ref": "#/components/schemas/LengthUom" }, { "nullable": true } ] }

[dylbarne]

so for some additional clarification/backstory, the actual source openapi.json document I am using in practice was generated through NSwag automatically, then I am consuming this to generate types for another project

I do not have a reason to believe that the generated json input is incorrect (having same overall nullable nested type structure I gave in my sample), I would think the generated types behavior would be consistent for same original source json regardless of package version change and would not require any modification?

[horiuchi]

The changes in v3.14.0 depend on the points made in #513 below. I am sure that this is a corrective change to this issue. And the bug in this issue was in the form of nullable being ignored.

However, the generated type is inappropriate. The intent of the schema is that all types in oneOf are nullable, but the generated result is that all types in oneOf are also null types.

There are many different ways of using allOf, oneOf, and anyOf, we cannot support all patterns yet. Therefore, we recommend using a version earlier than v3.14 or changing your schema.

[dylbarne]

I see, thank you for the additional information/clarification (and for creating this package in general ❤️) and definitely not a problem I will just stick with the current version :) just figured I would raise issue in case was something legitimate to look into further