microsoft / microsoft/TypeScript

Suggestion: make hover tooltips more readable by showing the generic parameters names instead of their value (in some cases)..

Open
#62,634 3 comments 1 reaction 0 assignees View on GitHub

Nobody has claimed this yet.

Awaiting More Feedback Suggestion
Dominant language
Go
Stars
111k
Forks
14.3k
Avg merge
2d 4h
Merged PRs (30d)
132

Description

### 🔍 Search Terms

tooltip generic parameters
expandable hover
format hover

Related issues:
- https://github.com/microsoft/TypeScript/issues/59029

I searched for both open and close issues, didn't found a duplicate, maybe I didn't use the correct search terms.

### ✅ Viability Checklist

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

### ⭐ Suggestion

For readability sake, when displaying type info in the hover tooltip, it is better (in some cases) to show the generic parameters' names instead of their value.

The rule could be that when a generic type parameter exceed a certain size, to show its name instead of its value (with the possibility to expand it).

### 📃 Motivating Example

```ts
function foo>(o: T) {
return class X {
constructor(a: number, b: string) {}
}
}

const X = foo({
f1: 34, f2: 34, f3: 34, f4: 34, f5: 34, f6: 34, f7: 34, f8: 34, f9: 34, f10: 34,
});

new X(12, "ok")
```

[Playground Link](https://www.typescriptlang.org/play/?#code/GYVwdgxgLglg9mABMOcA8AVRBTAHlbMAEwGdEAlbCOAJyLRKhpjAHMAaRAQzAE8A+fgAo4ALkQYAlIgDeAKESLENbFBA0kEADZcSZABqyFSk9TCMaIaLSFdxYEAFsARthqdn4iy1bSZAX2NFQMC5M0ZEQwBeZFQheRNgAEZxAGYAFk5gACY0zORUvKz0ouQAVlLgADZKgHZKgA5KgE5KpIAGIrl-SQBuOTkwbAB3SKEk7PYAIjgAayn2SSA)

When editing `new X()` arguments, the following tooltip is showing:
```
X(a: number, b: string): foo<{ f1: number; f2: number; f3: number; f4: number; f5: number; f6: number; f7: number; f8: number; f9: number; f10: number; }>.X
```

This can quickly become hard to read if the generic parameters are complex. The following would be easier to read (while keeping the ability to expand it*).
```
X(a: number, b: string): foo.X
```

_*Well, maybe expansion is not always the solution, and instead of showing the full type definition, to be able to browse the type, e.g. clicking on "T" to show its value (in another hover or by expanding it). Could be more appropriate when we want more precision on one part of the type, not on the whole type.

*Note: TS Playground doesn't seem to have the expandable hover tooltip feature._

### 💻 Use Cases

1. What do you want to use this for?

Improve hover tooltip readability.

2. What shortcomings exist with current approaches?

Tooltip can be hard to read.

3. What workarounds are you using in the meantime?

Some VSCode extensions, enable to "prettify" hover tooltips to some extends (e.g. MylesMurphy.prettify-ts).

The alternative would be to format the output to improve readability:
```
X(
a: number,
b: string
): foo<
{ f1: number; f2: number; f3: number; f4: number; f5: number; f6: number; f7: number; f8: number; f9: number; f10: number; }
>.X
```

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Reproduce the motivating example using the linked TypeScript Playground and inspect the reported hover tooltip output. No repository file, test, or implementation entry point is named, so first clarify the size threshold, expansion behavior, and expected generic-parameter display. Done means the hover output is more readable while retaining an appropriate way to inspect the underlying type.

Written by the indexing model from the issue text.

Assessment

Tech stack
typescript
Domain
developer-experience, tooling
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.