When using labels on underlying schemas of labeled Joi.alternatives, the Joi.alternatives' label overwrites the labels of the underlying schemas. I think this is a bug and therefore propose the changes in this PR.
Based on reading existing tests, I assume passing labels from Joi.alternatives to underlying schemas is wanted, though I do not believe this should be the case when the underlying schemas already have their own labels. The fact that I am not breaking any existing tests with these changes further reinforces my belief that this may be a bug. I only added a few new tests to cover the behavior introduced in my changes.
Background:
In my project, I am using joi-to-swagger to convert Joi schemas to OpenAPI-compatible schemas. In case of Joi.alternatives, this leads to anyof or oneOf (meaning this property can have any/one of the following schemas) , where the schema labels are useful to be able to differentiate the specific alternatives at first glance instead of having a default generic label for each one (object, string, number, ...). When I use nested Joi.alternatives, the nested alternatives all take the parent's label, which results in me being unable to tell the difference at first glance when reading the generated OpenAPI documentation (see screenshots below).
When using labels on underlying schemas of labeled Joi.alternatives, the Joi.alternatives' label overwrites the labels of the underlying schemas. I think this is a bug and therefore propose the changes in this PR.
Based on reading existing tests, I assume passing labels from Joi.alternatives to underlying schemas is wanted, though I do not believe this should be the case when the underlying schemas already have their own labels. The fact that I am not breaking any existing tests with these changes further reinforces my belief that this may be a bug. I only added a few new tests to cover the behavior introduced in my changes.
Background:
In my project, I am using joi-to-swagger to convert Joi schemas to OpenAPI-compatible schemas. In case of Joi.alternatives, this leads to
anyof
oroneOf
(meaning this property can have any/one of the following schemas) , where the schema labels are useful to be able to differentiate the specific alternatives at first glance instead of having a default generic label for each one (object, string, number, ...). When I use nested Joi.alternatives, the nested alternatives all take the parent's label, which results in me being unable to tell the difference at first glance when reading the generated OpenAPI documentation (see screenshots below).Take the following example:
Current output
Expected output
Resulting OpenAPI documentation
Current behavior
Expected behavior