You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
feat: ✨ handle grouped errors under the enum constraint (#183)
# Description
This PR handles grouped errors at
`$.resources[x].schema.fields[x].constraints.enum`. It's the worst one
yet!
This schema node is deeply nested, so handling errors here is a little
more complex.
The situation is the following: for each field, you can list the allowed
values for that field under `"constraints": {"enum": [...]}`. Depending
on the type of the field, the type of the values in `enum` can be
different. Sometimes it's straightforward (e.g. for string fields, enum
values have to be strings), but sometimes the schema for `enum` is more
permissive (e.g. for number fields, enum values can be either numbers or
strings). However, you cannot mix types.
If `enum` has mixed types or if some of the values are the wrong type,
all sub-schemas under `enum` flag errors. These are usually
contradictory, e.g., for a number field `[1, "inf"]` will alert both
because 1 is not a string and because "inf" is not a number...
The logic in the function:
- if the error is not even for the current field type -> remove all
errors
- if there are any errors on the `enum` property itself (not an array,
duplicate items, etc.) -> keep only these
- the remaining errors are all about the individual values in the enum
array being the wrong type
- if the values are not all the same type -> flag only this
- if they are all the same type -> flag that this is the wrong type
Part of #15
Needs an in-depth review.
## Checklist
- [x] Formatted Markdown
- [x] Ran `just run-all`
0 commit comments