More flexible handling of circular types with "typeof function" inference #58616
Description
🔍 Search Terms
"is referenced directly or indirectly in its own type annotation.ts(2502)"
"self-referencing types"
"circular types"
...
✅ 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
I would like to be able to infer type of a function A that calls another function B, returning its value, relying on parameters of function A (not sure if the description is good, see the code snippet).
📃 Motivating Example
function foo(arg: Parameters<typeof bar>[0]) {
return arg;
}
function bar(arg: string) {
return foo(arg);
}
The code above, obviously, would be unable to infer return type. But hypothetically it's possible to extract its parameters.
💻 Use Cases
More flexible type inference. Currently there is no workaround for this problem. My personal use-case is to produce less types while I define service and controller for my back-end. I've simplified the code to remove unnecessary types.
class ReportController {
static createReport(body: { reportName: string }) {
return ReportService.createReport(body);
}
}
class ReportService {
static createReport(body: Parameters<typeof ReportController.createReport>[0]) { // body is "any" + error
// ...
}
}At this case body is clearly { reportName: string } but because of the restriction I'm not able to use it. At this example I can move body to a type variable but in practice it's more complicated because of other inferences and I would need to define body type for each controller method outside of the classes.