Analyzing Type Inference Issues When Returning Promises in Async Functions in TypeScript

Problem Background

In TypeScript development, we frequently encounter scenarios where async functions return Promises. Consider the following two functions:

const whatever1 = (): Promise<number> => {
    return new Promise((resolve) => {
        resolve(4);
    });
};

const whatever2 = async (): Promise<number> => {
    return new Promise((resolve) => {
        resolve(4);
    });
};

From a JavaScript runtime perspective, these two functions should exhibit identical behavior. However, in TypeScript, the second function using the async keyword reports a type error:

Type '{}' is not assignable to type 'number'.

Type Inference Mechanism Analysis

To understand the root cause of this issue, we need to deeply analyze TypeScript's type inference mechanism. First, consider the type inference of the Promise constructor:

const p = new Promise((resolve) => {
    resolve(4);
});

In this example, TypeScript infers the type of p as Promise<{}> rather than the expected Promise<number>. This is a known issue with open discussions in TypeScript's GitHub repository.

Type Compatibility Rules

Why does the first function whatever1 pass type checking while the second function whatever2 reports an error? This involves TypeScript's type compatibility rules.

In whatever1, Promise<{}> is considered compatible with Promise<number> because Promise essentially has only a then method. According to TypeScript's function parameter bivariance rules, these two Promise types are compatible in terms of method signatures.

However, in async functions, the situation differs. The async keyword is designed to allow developers to write asynchronous code in a synchronous manner, automatically wrapping return values in Promises at the underlying level. In this context, TypeScript attempts to directly compare the return value type with the function's declared return type, and the {} type obviously cannot be assigned to the number type.

Solutions

Several effective solutions exist for this problem:

Solution 1: Explicit Generic Parameter Specification

The most direct solution is to explicitly specify generic parameters when creating the Promise:

const whatever2 = async (): Promise<number> => {
    return new Promise<number>((resolve) => {
        resolve(4);
    });
};

Solution 2: Using Promise.resolve

Another concise approach is to use Promise.resolve:

const whatever4 = async (): Promise<number> => {
    return Promise.resolve(4);
};

const whatever6 = async (): Promise<number> => Promise.resolve(4);

Solution 3: Combining with await

In some cases, you can combine with the await keyword:

const whatever3 = async (): Promise<number> => {
    return await new Promise<number>((resolve) => {
        resolve(4);
    });
};

const whatever5 = async (): Promise<number> => {
    return await Promise.resolve(4);
};

const whatever7 = async (): Promise<number> => await Promise.resolve(4);

Deep Understanding

The emergence of this issue reflects some subtleties in TypeScript's type system regarding Promise handling. While from a human perspective, resolve(4) should clearly produce Promise<number>, TypeScript's type inference mechanism cannot accurately infer the generic type in this scenario.

It's noteworthy that this issue only becomes apparent when using the async keyword, indicating special treatment of async functions during type checking. In regular functions, type errors are hidden due to Promise type compatibility rules.

Best Practice Recommendations

Based on the above analysis, we recommend following these best practices in TypeScript projects:

1. Always explicitly specify generic type parameters when creating Promises
2. Prefer using Promise.resolve to create resolved Promises
3. Pay attention to return value type consistency in async functions
4. Regularly monitor TypeScript version updates, as this issue may be improved in future versions

By following these practices, you can avoid similar type errors while improving code readability and maintainability.