fix(openapi): support nullish consts

[WoH]

Checklist

• run npm run test and npm run benchmark
• tests and/or benchmarks are included
• documentation is changed or added
• commit message and code follows the Developer's Certification of Origin
  and the Code of conduct

[Uzlopak]

seems right, but I would like to have a second opinion by @ivan-tymoshenko

[ivan-tymoshenko]

I'm not really deep into this library. The only thing I would check (add a test) is how it would work with nullable keyword and type null. For example:

{
  "type": "string",
  "nullable": false,
  "const": null
}

and

{
  "type": "string",
  "const": null
}

Both these schemas are invalid (there is no value that would match them). You want to be sure that you handle cases like that correctly.

[mcollina]

lgtm

[WoH]

I'm not really deep into this library. The only thing I would check (add a test) is how it would work with nullable keyword and type null. For example:

{
  "type": "string",
  "nullable": false,
  "const": null
}

and

{
  "type": "string",
  "const": null
}

Both these schemas are invalid (there is no value that would match them). You want to be sure that you handle cases like that correctly.

In both of these cases I'd argue it's not the job of this library to figure out what may have been implied, but just convert it to an equally useless (albeit OAS compatible) schema.

I would like to mention that one could make an argument for converting:

{
  "const": null
}

to:

{
  "enum": [null],
  "nullable": true // with this added
}

but that is is not required from my understanding of the spec (which seems to be in line with the swagger-validator).