feat: allows arrays with oneOf/anyOf/allOf definitions to pass lint #329
Conversation
jcsackett
force-pushed
the
feat/complex-types-in-arrays
branch
from
52ed2aa to
cde08f5
Compare
| things: { | ||
| type: "array", | ||
| items: { | ||
| oneOf: [], |
There was a problem hiding this comment.
Should we pass if it's an empty composite type though? I think we should require at least one concrete type in here.
I suppose the worst pathological case would be nested composite types with nothing at the bottom -- so to be really comprehensive we should do a recursive descent to make sure all "leaf-node" type-paths are defined (not empty composites). This would be the most formally-correct solution.
For example, this type contains a whole lot of choices, all leading to "no type defined":
items:
oneOf:
- oneOf: []
- {}
- anyOf:
- allOf: []
- {}
A helper function isCompletelyDefinedType could probably tackle this.
A band-aid quick-fix solution might be to check that "all composites must contain one or more simple non-empty type" and deal with the formal solution in a followup. AFAIK no one's trying to nest composites at the moment (but it may happen unintentionally later!)
There was a problem hiding this comment.
I was under the impression that there were other checks for composite types having concrete types--if not, wouldn't it be better to have those checks across all schemas rather than making that part of this check?
There was a problem hiding this comment.
There might be... I'll have to look (it's been a little while)
There was a problem hiding this comment.
Did a quick check and there aren't; I'm going to file an issue for validating that composites are completely typed, and go with a band-aid helper in this branch.
| const oneOf = property.raw.items["oneOf"]; | ||
| const allOf = property.raw.items["allOf"]; | ||
| const anyOf = property.raw.items["anyOf"]; | ||
| if (!oneOf && !allOf && !anyOf) { | ||
| throw new RuleError({ | ||
| message: "type was not found array items", | ||
| }); | ||
| } |
There was a problem hiding this comment.
Recommend turning this into a helper, for incremental improvement as described above. Asserting a non-empty type seems like a generally useful thing we may want for property types as well as array item types.
|
🎉 This PR is included in version 1.19.0 🎉 The release is available on: Your semantic-release bot 📦🚀 |
No description provided.