You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
List of keywords you searched for before creating this issue. Write them down here so that others can find this suggestion more easily and help provide feedback.
preserve type alias in quick info
β Viability Checklist
My suggestion meets these guidelines:
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.)
Preserve type aliases in declarations in quick info of Visual Studio Code instead of replacing them with their definitions.
π Motivating Example
I am using type aliases as domain types in order to document their range or meaning, f.e.:
/** Non-negative integer number determining the offset of an item from the first item in a sequence, see {@link isOffset()} */exporttypeOffset=number/** Determines whether `candidate` is a valid {@link Offset}. * * Equivalent to `Number.isSafeInteger(candidate) && candidate >= 0` * * @returns `true` if `candidate` is a non-negative safe integer */exportfunctionisOffset(candidate: unknown): candidate is Offset{ ... }/** Demonstrates how parameter `offset` does not need additional documentation */functiondemo(offset: Offset){ ... }
When looking at the quick info for demo() in Visual Studio Code, the type of the parameter offset is resolved to number. It would be more helpful, if the declared type Offset would be used, especially if it would be a clickable link referring to the type's documentation.
Using domain types in this manner would reduce the necessity to document the range of parameters or the confusion of what numbers would be valid input when documentation is not provided.
The parameter name is often sufficient to document the semantics of such a domain type, but this can only be a hint, while a reference to a domain type can provide a more meaningful/formal definition (as in this example referencing isOffset) and thus more value.
π» Use Cases
The text was updated successfully, but these errors were encountered:
Suggestion
π Search Terms
List of keywords you searched for before creating this issue. Write them down here so that others can find this suggestion more easily and help provide feedback.
preserve type alias in quick info
β Viability Checklist
My suggestion meets these guidelines:
β Suggestion
Preserve type aliases in declarations in quick info of Visual Studio Code instead of replacing them with their definitions.
π Motivating Example
I am using type aliases as domain types in order to document their range or meaning, f.e.:
When looking at the quick info for
demo()
in Visual Studio Code, the type of the parameteroffset
is resolved tonumber
. It would be more helpful, if the declared typeOffset
would be used, especially if it would be a clickable link referring to the type's documentation.Using domain types in this manner would reduce the necessity to document the range of parameters or the confusion of what numbers would be valid input when documentation is not provided.
The parameter name is often sufficient to document the semantics of such a domain type, but this can only be a hint, while a reference to a domain type can provide a more meaningful/formal definition (as in this example referencing
isOffset
) and thus more value.π» Use Cases
The text was updated successfully, but these errors were encountered: