Repository navigation
Type string not assignable to specific string inside Promise.then return value #29815
Description
TypeScript Version: 3.4.0-dev.201xxxxx
Search Terms:
"typeof string is not assignable to"
"promise"
Code
interface ITest {
name: 'test'
}
const createTestAsync = (): Promise<ITest> => Promise.resolve().then(() => ({ name: 'test' }))
// The same works if you write:
// const createTestAsync = (): Promise<ITest> => Promise.resolve({ name: 'test' })
const createTest = (): ITest => {
return { name: 'test' }
}Expected behavior:
Expect both sync and async functions (createTest and createTestAsync) to compile without errors
Actual behavior:
createTestAsync throws the following compilation error:
Type 'Promise<{ name: string; }>' is not assignable to type 'Promise<ITest>'.
Type '{ name: string; }' is not assignable to type 'ITest'.
Types of property 'name' are incompatible.
Type 'string' is not assignable to type '"test"'.
Related Issues:
#29078
Further notes
Hi there, first time I'm interacting with the Typescript github repo. I wasn't able to find any issues which described the exact same problem but I wasn't sure exactly what search terms to use so apologies if there are duplicates. Furthermore, I am wondering whether there is something inherent in how Promises work which makes this problem occur - if so, I would love to be educated on the matter! :)
If there is any other information I can provide, please let me know.
Activity
ahejlsberg commentedon Feb 10, 2019
This is related to type inference where the target is a union of type variables.
For reasons that are lost to history we don't make inferences to type parameters in unions with other type parameters. I think it was because we previously lacked the ability to assign lower priority to such inferences (as they are more speculative), but we have that ability now. So, when inferring from
Promise<XXX>toPromise<T | U>we ought to make a lower priority inference ofXXXto bothTandU. Doing so would solve your issue. I will look at making this change.ahejlsberg commentedon Feb 10, 2019
For example, we currently get this wrong:
We ought to infer
"a"for bothTandU.