-
-
Notifications
You must be signed in to change notification settings - Fork 356
clarify that type must be a non-empty array
#1560
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is great. All of these edge cases and what is technically possible can be very confusing.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm a little reluctant to approve a breaking change without documented consensus and an ADR, but I think it's ok in this case because the support for type with an empty array was never reliable because the meta-schema has included "minItems": 1 since at least draft-04 (I didn't bother looking further back). That means that implementations that use the meta-schema to validate schemas (probably most of them) have been rejecting type with an empty array.
What kind of change does this PR introduce?
clarification
Issue & Discussion References
Summary
Clarifies that
typeas an array must be non-empty.Does this PR introduce a breaking change?
Technically yes? @awwright did point out that there is a niche use case as an alternative to
{not:{}}, but the keyword certainly wasn't intended to be used this way. Also, given that we present{not:{}}as the analog tofalse, it's extremely unlikely that anyone will be using it this way on purpose.