Expose TypeChecker.getAwaitedType for public api

[yeonjuan]

🔍 Search Terms

getAwaitedType
public api

✅ Viability Checklist

• This wouldn't be a breaking change in existing TypeScript/JavaScript code
• This wouldn't change the runtime behavior of existing JavaScript code
• This could be implemented without emitting different JS based on the types of the expressions
• This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)
• This isn't a request to add a new utility type: https://github.com/microsoft/TypeScript/wiki/No-New-Utility-Types
• This feature would agree with the rest of our Design Goals: https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals

⭐ Suggestion

TypeChecker.getAwaitedType is currently an Internal API. I propose to expose it as a public API.

TypeScript/src/compiler/types.ts

Lines 4971 to 4972 in 4641004

	/** @internal */
	getAwaitedType(type: Type): Type | undefined;

📃 Motivating Example

In typescript-eslint, I'm working on improving the no-unsafe-return rule to check for types that returns Promise<any>.

• Enhancement: [no-unsafe-return] Disallow return Promise<any> typescript-eslint/typescript-eslint#8674
• feat(eslint-plugin): [no-unsafe-return] check promise any typescript-eslint/typescript-eslint#8693

To implement this feature, we need to get the awaited type of the promise. And it looks like this functionality is already implemented in TypeChecker getAwaitedType.
If getAwaitedType is provided as public, I think we can avoid duplicating the same logic in multiple tools that need similar functionality.

💻 Use Cases

1. What do you want to use this for? Use it in the typescript-eslint.

2. What shortcomings exist with current approaches?

3. What workarounds are you using in the meantime? There is a way to get the first type argument of a Promise generic. But it doesn't catch some cases. (feat(eslint-plugin): [no-unsafe-return] check promise any typescript-eslint/typescript-eslint#8693 (comment))

[RyanCavanaugh]

@rbuckton any objections? This seems fine to me

[jakebailey]

I've wanted to do this for a while to simplify ts-eslint (but apparently forgot to make an issue).