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
Mapped types in TypeScript accept Unions as the constraint type, and the resulting output (in TS) will be similar to Distributive Conditional Types. Take the following code, for example:
The resulting type would still be a Union, but with a: string being mapped to a: number, because the mapping is applied to each Union case individually (the LSP shows MyObject to equal MappedUnion<A> | MappedUnion<B>).
The problem is that the MappedTypeNodeParser doesn't handle this correctly, as this case is not covered at all. It generates the constraintType and keyListType (confusing names) by passing mappedNode.typeParameter.constraint to a child parser. The parser will be a TypeOperatorNodeParser, which will, in turn, return all of the possible keys for that type parameter (T). When T is a Union, though, it will return a flat list for its keys. Going back to MappedTypeNodeParser, there's no differentiation if that flat list of keys comes from a Union or an object, it will just assume that it's an object and construct the mapped type:
if(keyListTypeinstanceofUnionType){// Key type resolves to a set of known propertiesreturnnewObjectType(id,[],this.getProperties(node,keyListType,context),this.getAdditionalProperties(node,keyListType,context),);}
This means that instead of getting a schema like this for the original example:
Hey @arthurfiorette thanks for responding! Unfortunately I don't have the time to really dive into and understand the code right now, I did try some stuff but the Context handling that you guys use is a little more complex than I initially thought. I did start out by making the unit test 😛 but I won't be able to fix this in the coming weeks
Mapped types in TypeScript accept Unions as the constraint type, and the resulting output (in TS) will be similar to Distributive Conditional Types. Take the following code, for example:
The resulting type would still be a Union, but with
a: string
being mapped toa: number
, because the mapping is applied to each Union case individually (the LSP showsMyObject
to equalMappedUnion<A> | MappedUnion<B>
).The problem is that the
MappedTypeNodeParser
doesn't handle this correctly, as this case is not covered at all. It generates theconstraintType
andkeyListType
(confusing names) by passingmappedNode.typeParameter.constraint
to a child parser. The parser will be aTypeOperatorNodeParser
, which will, in turn, return all of the possible keys for that type parameter (T
). WhenT
is a Union, though, it will return a flat list for its keys. Going back toMappedTypeNodeParser
, there's no differentiation if that flat list of keys comes from a Union or an object, it will just assume that it's an object and construct the mapped type:This means that instead of getting a schema like this for the original example:
we get this:
(it, by mistake, turns it into an Intersection by using the flat list of keys for that Union as properties for a new object)
The text was updated successfully, but these errors were encountered: