Closed rattrayalex closed 3 years ago
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!
Hi there,
I am interested in using this for an OpenAPI use-case. Currently,
.allow(null)
will outputtype: ['string', 'null']
which may be correct json-schema, but it is not good for OpenAPI.Would you be open to something like this?
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!