Description
🔍 Search Terms
unset type parameter default
✅ 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
The suggestion is to add a keyword that says "I don't need to specify this optional type parameter, I am only passing by to a later one, please resolve to whatever the fallbace default type
📃 Motivating Example
Considering the case:
import express from 'express'
interface CreateUserParams {
name: string
age: number
}
export type CreateUserRequest = express.Request<
Record<string, string>, // ❌ unrelated, but there's no way if skipping this
any, // ❌ could've specified it, but decided to not bother
CreateUserParams // ✅ actually what is needed and relevant
>All of the type parameters of express.Request are optional. In the case when I only need to specify the third parameter, there is no way of skipping the first two. Instead, I have to go to the definition, see what the fallback type is, and provide the fallback type here explicitly; this gets words if the fallback type isn't exported.
Sometimes this can be mitigated by a better design, sometimes not.
The suggestion is to add a keyword (e.g., CSS's unset or SQL's default) that would do the lookup itself:
export type CreateUserRequest = express.Request<unset, unset, CreateUserParams>This might be a breaking change for codebases where unset is an existing identifier. If that's a concern, consider ? as the keyword:
export type CreateUserRequest = express.Request<?, ?, CreateUserParams>💻 Use Cases
- What do you want to use this for? – Skipping optional parameters in generics defined by upstream libraries.
- What shortcomings exist with current approaches? – The need to lookup the definition.
- What workarounds are you using in the meantime? – I look the definition up.