kenspirit/joi-to-json

Ability to output `nullable: true` and other OpenAPI attributes

rattrayalex opened this issue ยท 6 comments

Hi there,

I am interested in using this for an OpenAPI use-case. Currently, .allow(null) will output type: ['string', 'null'] which may be correct json-schema, but it is not good for OpenAPI.

Would you be open to something like this?

convert(joi.string().allow(null), {target: 'openapi'})
// {type: 'string', nullable: true}

There are many subtle differences in what kinds of json-schema OpenAPI will accept, and many people who are using json-schema are doing it for OpenAPI, so some kind of "openapi mode" might be useful in other ways too.

Of course, if you don't want to support this, I understand.

Thanks!

Ah, I guess, your other library has a function _convertJsonSchemaToSwagger which handles this, perhaps you would be happy to export that from this other library?

For myself, I would probably still prefer it for this library to have openapi support as an option, but if that is not to your taste, perhaps joi-route-to-schema could export this method too?

@rattrayalex Thanks for your advice. For a quick solution, I will first export the _convertJsonSchemaToSwagger out. Version 1.2.2 is released for it.

To be honest, these two libraries are highly co-related and I will reconsider if I need to reorganize them somehow and surely we do often use the Joi for OpenAPI.

Great, thank you!

Yes, I agree. It is a little tricky, because I think openapi is a very common use-case for json-schema, but it really has its own flavor. They are not the same in fact. But that is ok!

Fortunately the name of this library joi-to-json gives you some wiggle room; I think this is the perfect library for using Joi to build json-schemas and openapi specs.

So maybe users of this library could either do:

import { joiToOpenAPI } from 'joi-to-json'
// or
import { joiToJsonSchema } from 'joi-to-json'

or something similar.

The former would allow/use nullable: true, deprecated, examples, x-foo, etc, while the latter would just be strict json-schema. As I'm sure you know the docs for the differences are here.

I wonder if this library should also provide extensions to Joi to allow some of these additional fixed fields and extension fields.

Personally I think joi-route-to-swagger should be responsible for the fancier stuff, like routes, middleware, etc, that are less directly related to joi.

What do you think?

@rattrayalex Yes, I did have that in mind.

@rattrayalex Version 2.0.0 supporting OpenAPI is out. Currently it only supports nullable, x-foo and will add more fields later. :)

Ok, great! I hope to give it a try soon!