Optional reference property in an object scheme

[dankinsoid]

I try to describe a scheme with an optional reference property

.object(
  properties: [
    "enumValue": .reference(.component(named: "SomeEnum")).optionalSchemaObject(),
    "username": .string(required: true),
    "password": .string(required: true)
  ]
)

but .optionalSchemaObject() modifier doesn't have effect on a reference scheme I cannot make "SomeEnum" required itself, and even I do, it doesn't help

Expect:

{
    "properties" : {
      "enumValue" : {
        "$ref" : "#\/components\/schemas\/SomeEnum"
      },
      "password" : {
        "type" : "string"
      },
      "username" : {
        "type" : "string"
      }
    },
    "required" : [
      "password",
      "username"
    ],
    "type" : "object"
  }

Got:

{
    "properties" : {
      "enumValue" : {
        "$ref" : "#\/components\/schemas\/SomeEnum"
      },
      "password" : {
        "type" : "string"
      },
      "username" : {
        "type" : "string"
      }
    },
    "required" : [
      "enumValue",
      "password",
      "username"
    ],
    "type" : "object"
  }

[mattpolzin]

Thank you for the bug report.

Unfortunately, this is something I can't change in version 2.x because my use of enum means that introducing the ability for references to carry optionality would be a breaking change.

Fortunately, this is something that I have fixed in the version 3.x alpha releases currently available. There are a number of breaking changes, including the one needed to support reference optionality, but if you want to stick with OpenAPI v3.0.x (as opposed to the newer OpenAPI v3.1.x) then the changes needed are relatively small. You'll want to read through the release notes for each of the alphas though, because at least one of the breaking changes related to switching away from an enum to a struct can be a gotcha that the compiler will not always catch.

Feel free to reopen this issue if needed, but for now I will close it as "fixed in the current pre-release versions."

[dankinsoid]

@mattpolzin Thank you, I will happy with 3.x version. I had an awkward situation, I could not find your library in time and implemented my own and now that I found out about OpenAPIKit I want to use it in my VaporToOpenAPI library instead of my SwiftOpenAPI because your is popular and well tested, but I have some little blocks like this one.

[mattpolzin]

@dankinsoid i really appreciate you bringing bugs and feature requests to the table. Feel free to continue to report things against either v2.x or v3.x of OpenAPIKit and I'll happily figure out whether the problem can be fixed in a v2.x patch and then ported forward to v3.x (ideal situation) or whether it needs to be fixed in v3.x instead.