fix: do not override existing labels of underlying schemas in alternatives #3001
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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