fix(typed-enum): respect nullable in case of OAS3 document

[P0lip]

Fixes #1353.

Checklist

• Tests added / updated
• Docs added / updated

Does this PR introduce a breaking change?

• Yes
• No

[philsturgeon]

I'm not sure I understand this implementation. It seems like OAS2 says no this is not ok (because it doesnt support nullable) and OAS3 says "yeah this is fine" because it does support nullable, and that enum is accepting null as a deviation to "type: string" because nullable is there...

I dont think this is the right solution.

I think the enum should not have null in it, that seems more like user error. The enum constricts the strings that can be used as a value, and nullable makes null be another value that could be used, but that doesn't mean null is now a valid enum value. It can't be, because everything in that enum should be a string...

[P0lip]

I'm not sure I understand this implementation. It seems like OAS2 says no this is not ok (because it doesnt support nullable) and OAS3 says "yeah this is fine" because it does support nullable, and that enum is accepting null as a deviation to "type: string" because nullable is there.

This is what we do in case of schema function.

I think the enum should not have null in it, that seems more like user error

Why so? AFAIK type cannot be an array in case of OAS3, therefore user has to rely on nullable as there is no way to specify "type": ["null", "string"].

I'm not sure how nullable works in case of enum, however, so I might be wrong.

[philsturgeon]

I've read a whole lot of back and forth on this issue but it seems like what you've done is correct, but keep in mind this isn't anything to do with type arrays.

From here: https://github.com/OAI/OpenAPI-Specification/blob/master/proposals/003_Clarify-Nullable.md

It seems like nullable: true will only work for a type: string with an enum if null is specified as an option. Who knew?!

If that is what this code is doing, please carry on, but the OAS2 example should maybe use x-nullable as thats a very common vendor extension in OAS2. OAS2 is barely usable without it.

[philsturgeon]

We can go ahead with this. OAS2 users with x-nullable: true might notice trouble here, but it might not be a thing.

[P0lip]

If that is what this code is doing, please carry on, but the OAS2 example should maybe use x-nullable as thats a very common vendor extension in OAS2. OAS2 is barely usable without it.

Ah yeah, I think we actually even have a bug report for it.
#1359
I'll fix it in a separate PR, since I'll need to touch other parts of code.