Typescript: Add full type hover popup to VS Code commands

[Arlen22]

Several issues have been opened for this problem, but they have been closed as a duplicate of an issue which barely mentions the problem, let alone addresses it: https://github.com/microsoft/vscode/issues/64566

The closed issues are:

• https://github.com/microsoft/vscode/issues/66405
• https://github.com/microsoft/vscode/issues/76480
• https://github.com/microsoft/vscode/issues/66405

The problem is simple. The three dots means you can't copy and paste definitions like you used to be able to. This is an absolutely essential feature because TypeScript isn't even close to being used everywhere, and the intellisense of Javascript files inside TypeScript files is way worse than inside Javascript files. This basically means the easiest way to create a d.ts file is to copy the type definition in the hover inside Javascript and then paste it into a d.ts file so TypeScript files can use it. It also helps me debug overloads and unions when things are going awry.

Even just a command that would popup the hover with the full definition instead of the abbreviated definition would be incredibly useful. Currently the shortcut is Ctrl+k, Ctrl+i for the abbreviated definition, so I take it there is a command behind it that can be typed into the command list (ctrl+shift+p). So even just adding the command for people to manually add a shortcut for would be really useful.

I can work around it, but I spend hours more time per week because of it.

[mjbvz]

@Arlen22 This is what microsoft/vscode#64566 is about: being able to expand the error to see more detail.Even in JS there are types that are too large to display (or infinite), so it is not possible to just always expand the ... eagerly.

Can you provide sample code that shows when the ... gets in the way

[Arlen22]

An infinite recursion should simply be marked as infinite (same color as never) indicating that some level of recursion is involved, I suppose, and the user could then end the recursive reference in some way in order to get a complete type output.

Normally the types I work with are not too large to display. If they are I can usually break them apart into smaller chunks in one way or another, either by making minor edits to the Javascript or by handwriting a Record, or stuff like that.

It's just that the ... prevents this from working at all, especially since I don't really know whether all ... are referring to the exact same type or what that type is. And then someone mentioned | ... and 4 more ... | in a string union, which obviously completely breaks copy and paste.

[mjbvz]

Can you provide some specific code examples?

[Arlen22]

Array<{ 
  "server_id": number; "server_uri": string; "itemType": string; "key": string; 
  "title": string; "summary": string; "thumbnail": string; "videocover": string; 
  "url": { "H264": string[]; "location": string; }; 
} | { "itemType": string; ... 7 more ...; "url"?: undefined; }>.shift(): {
    "server_id": number;
    "server_uri": string;
    "itemType": string;
    "key": string;
    "title": string;
    "summary": string;
    "thumbnail": string;
    "videocover": string;
    "url": {
        "H264": string[];
        "location": string;
    };
} | {
    "itemType": string;
    ... 7 more ...;
    "url"?: undefined;
}

[Arlen22]

ceTouchableFeedback<{
    onPress: () => void;
    object_id: number;
    name: "header" | "italic" | "bold" | "underline" | "repeat" | "link" | "search" | "image" 
| "key" | "code" | "map" | "table" | "th" | "circle" | ... 771 more ... | "snowflake-o";
    style: {
        ...;
    };
}>(options: TouchableFeedbackOptions<...>, ...children: any[]): any (+1 overload)

The name field is obvious and useless and I would just remove the contents or change them to a named reference, but the generic inside options: TouchableFeedbackOptions gives me no information, and I critically need to know what the exact properties are being brought in.

[mjbvz]

Moving upstream to get more feedback from the TS Team

[Ciantic]

This is same request I had in the diagnostics issue.

Use case I had is that I often found myself seeing a type in the hover tip, and copying it out. It never worked after the changes.

I actually don't understand why the hover tip needs to be abbreviated with three dots. It has a scrollbar. It's perfect abbreviation itself, you can expand it by scrolling! Even if the three dots were expandable by clicking, it would be worse UI in terms of usability, scrolling is easier way to "expand" the view.

P.S. Recursive types are an outlier, I don't mind having dots for them (since it can be infinite). I think in general VSCode should try to show as much as possible of the type, and user can scroll if they wish to see more of the type.

[Arlen22]

Can we somehow make this a VS Code setting? I guess this is in Typescript now, so whatever the equivalent would be here.

[Arlen22]

And now this evening I am diagnosing type problems and it is not showing me a second type that I know is different than the first one that it is showing me. It’s a union on the values of an object and it is only expanding the first type in the union.

[DanielRosenwasser]

Just as a heads up, there's a noErrorTruncation option which you can set to true, which I believe gives you the behavior you're looking for.

[Ciantic]

Ah, apparently it doesn't work always.

Btw, this is a duplicate of https://github.com/Microsoft/TypeScript/issues/26238

[Arlen22]

I desperately need this feature. Infer types from usage is giving me three dots when I use it if the original type has three dots. I also can't debug type problems because the three dots is not dependable and never guarantees that any particular type is actually repeated.

Since this is a TypeScript feature I can just build a custom TypeScript package, but I don't know where I would do that. Any ideas?

[lake2]

same issue + 1