Repository navigation
resolve() of a promise accepts undefined when explicit generic type is specified #36749
Description
I am confused. It well can be the result of ECMAScript spec or something, but all this doesn't make sense to me.
TypeScript Version: 3.7.x-dev.201xxxxx
Search Terms: promise undefined and I looked through all of the 5 pages + looked through FAQ
Code:
type TypeA = {
value: number;
}
const test = (): Promise<TypeA> => {
return new Promise<TypeA>(resolve => {
resolve(undefined); // Result of test() is Promise of TypeA. I return a promise that is resolved with undefined and it's ok for some reason.
});
};
const test2 = (): Promise<TypeA> => {
return Promise.resolve(undefined);
};
test().then(typeAInstance => {
// At this point here `typeAInstance` is of type TypeA and not! of `TypeA | undefined`
console.log(typeAInstance.value.toFixed())
});Expected behavior:
Both Functions should prevent me from doing writing stupid code at compile time.
Actual behavior:
Only second one does prevent me. First one allows runtime error to happened in the end.
Related Issues:
I don't understand where this undefined as one of the potential argument types is coming from:
My lib.es5.d.ts contains this:
declare type PromiseConstructorLike = new <T>(executor: (resolve: (value?: T | PromiseLike<T>) => void, reject: (reason?: any) => void) => void) => PromiseLike<T>;My lib.es2015.promise.d.ts contains this:
new <T>(executor: (resolve: (value?: T | PromiseLike<T>) => void, reject: (reason?: any) => void) => void): Promise<T>;
Activity
soswow commentedon Feb 12, 2020
As Rifat Nabi (@torifat) pointed out, it does complain appropriately in Flow.
https://flow.org/try/#0PQKgBAAgZgNg9gdzCYAoVAXAngBwKZgAqueAgmALxgDeqYYAbgIYwCueAXGAHasC2AIzwAnANyoAvqgDGcbgGcMYDHkWUwACgCUXAArC4fAJby8AHmL5SAPkq3a9YXgyth3HniT7DJ85bLWGk7ycDAMBBT2dPRgwaHhGqzcACZ4UEbceMla4vQSOZLisgpKKooATOraegbGphYkNnY00Y7Oru7edXgAdHFheIkpaRlZBRLiZRjaPRgAFnjcGthWAJIlTNzSEVH0xSEwvfAA5suN64qb2z3MbL0YcABiRgAeWdpakjlAA
jcalz commentedon Feb 12, 2020
duplicate of #22040
It's an optional argument, and therefore accepts
undefined.soswow commentedon Feb 12, 2020
Joe Calzaretta (@jcalz) yeah, seems to be a duplicate. This is really a shame. I raised it because this caused an issue in production for me just now and I was really surprised TS can't handle such a simple case.
If
resolveby default allows an optional argument, then all the.thencallbacks should be also expected to be called withundefinedregardless of the generic type defined.andrewbranch commentedon Feb 13, 2020
This came up recently in our team chat and it was surprising to several of us. According to Ron Buckton (@rbuckton):
So I’m going to leave this open so we can revisit it.
jcalz commentedon Feb 13, 2020
crosslinking to #27522
will this run afoul of #29131 ?
mbroadst commentedon Aug 13, 2020
Hi, I'm running into a similar problem with type specificity for a generic callback type in our code on the
mongodbnode driver. The current callback definition looks something like:Our desire is to explicitly disallow
undefinedfor the result type, and I was hoping this would do the trick:Alas it seems
undefinedequates tovoidin this case, so the elision of thevoidparameter isn't necessarily specific to thePromisecase.