Repository navigation
Function return type with array #33158
Description
TypeScript Version: 3.6.2
Search Terms:
map\array\return type
Code
const fetchCustomVariables = (): { name?: string; type?: string }[] => {
const variableList: { name?: string; type: string }[] = [];
return variableList.map(v => ({ nasme: v.name, type: v.type }));
};
Expected behavior:
Typescript complaints that array of objects generated by map doesn't match function return type.
Actual behavior:
Typescript doesn't complaint that array of objects generated by map doesn't match function return type.
Related Issues:
No
Activity
AnyhowStep commentedon Aug 30, 2019
AnyhowStep commentedon Aug 30, 2019
You're running into this thing called excess property checks for object literals. It isn't applied on non-object literals.
Without the explicit return type annotation on your
.map()callback function, basically anything is allowed.Then, the result of
.map()is not an object literal. So, it doesn't perform excess property checks and it allowsnasme, the excess property.deser commentedon Aug 30, 2019
Yes I saw that, but why typescript can't guess the type? And actually, seems, it already guesses it:
deser commentedon Aug 30, 2019
And...
mapkind of already knows the type, it knows what array it iterates (not any). Why do I need to repeat that type for map explicitly again?AnyhowStep commentedon Aug 30, 2019
It knows the type. It just isn't applying the excess property checks because it wasn't made to do so.
It's intentional.
One of these may help,
#28464 (comment)
#32537
#7481
Also, try looking up "excess property check" and "object literal".
It might turn up other stuff that explains the motivation for the current behaviour.
Might also include other workarounds you might find more agreeable
fatcerberus commentedon Aug 30, 2019
What I believe happens here is that
v => ({ ... }). Because there's no explicit type annotation on the lambda, it simply infers a structural type based on whatever it actually returns. This is right becausemapallows you to output anything you want - there's no basis for it to infer any specific contract on the return type at this point.map.v(the argument) is already the correct type as determined by contextual typing and the return type can be anything at all, so yes, it's fine.It simply asks whether
{ nasme: string | undefined, type: string }[]is structurally compatible with the return type offetchCustomVariables, and it is.If you want the excess property checks in the lambda, annotate its return type:
deser commentedon Sep 6, 2019
But typescript as far as I understood already infers return type of callback. It knows exactly what map will return.
I mean it's quite possible to me in such simple cases (when all entities of map will be definitely of the same type) to not return any from map, but infer type and return correct type
deser commentedon Sep 6, 2019
Even if types are different depending on conditions, it's quite possible to return union type... :)
thw0rted commentedon Sep 9, 2020
It looks like #40311 fixes this. Consider
We want the excess property
bto be flagged.Current (v4.0.2) Playground -- no error
PR Playground -- gives "may only specify known properties" error. 🎉 🎉 🎉