Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Option to expand computed TypeScript types on hover #94679

Closed
MKRhere opened this issue Apr 8, 2020 · 20 comments
Closed

Option to expand computed TypeScript types on hover #94679

MKRhere opened this issue Apr 8, 2020 · 20 comments
Assignees
Labels
feature-request Request for new features or functionality javascript JavaScript support issues typescript Typescript support issues upstream-issue-linked This is an upstream issue that has been reported upstream
Milestone

Comments

@MKRhere
Copy link

MKRhere commented Apr 8, 2020

When working with complex types, I often encounter types like this:

image

It's opaque enough that without understanding all the utils that are used and computing it in the head, it's hard to understand what type is being represented. I'd love to have a way to expand it into the fully resolved type, which in the case of the above example would be:

{
  a: number;
  b?: boolean | null | undefined;
  c: string;
  d: symbol;
}

The impl of actual utils I'm using are inconsequential; it's the same if we'd used Pick, Omit, or Partial. It'd be great to be able to expand computed types. I'm not sure whether the responsibility for this lies in VSCode or TypeScript, so if I should be moving this there, let me know :)

@MKRhere MKRhere changed the title Option to display computed TypeScript types on hover Option to expand computed TypeScript types on hover Apr 8, 2020
@MKRhere
Copy link
Author

MKRhere commented Apr 9, 2020

Update: I found this semi-decent hack that seems to force VSC/TSC to expand the types in some cases:

type Id<T> = {} & { [P in keyof T]: T[P] };

Wrapping a complex type with this mapped Id seems to work. I'll leave this here for anyone else who has the same problem, but I'd still like a solution without hacks.

@mjbvz mjbvz added this to the Backlog milestone Apr 14, 2020
@mjbvz mjbvz added feature-request Request for new features or functionality javascript JavaScript support issues typescript Typescript support issues labels Apr 14, 2020
@Eliav2
Copy link

Eliav2 commented Jun 22, 2020

also looked into this.
I've asked a question in stackoverflow.
maybe we can get it from somewhere here in the vs code base?

@MKRhere
Copy link
Author

MKRhere commented Jun 22, 2020

@Eliav2 I believe adding "noErrorTruncation": true, to your tsconfig.json has the side effect of expanding ... n more ... in your case.

The case I've asked about is to resolve complex types (maybe that's also part of your issue, but your question was about the 13 extra properties, so this should help you.)

@Eliav2
Copy link

Eliav2 commented Jun 22, 2020

you are right. but this is still a workaround to this feature request.
thanks! that helped me a lot!

@lydell
Copy link

lydell commented Jan 6, 2021

This works pretty well for me: https://stackoverflow.com/a/57683652/2010616

type Expand<T> = T extends infer O ? { [K in keyof O]: O[K] } : never;

@MKRhere
Copy link
Author

MKRhere commented Jan 7, 2021

@lydell I believe this works similarly to the solution I'd posted above. It's a great hack; I'm not really sure of edge cases--and this feature should still ideally be added to VSCode itself given how useful it is.

@shian15810
Copy link

shian15810 commented Jan 7, 2021

I have published a npm package for Expand and ExpandDeep based on the SO answer: https://www.npmjs.com/package/type-expand

@glenjamin
Copy link

It might be nice to gate this behind a modifier key, so we can toggle between expanded and unexpanded while the tooltip is up.

@MohammadKurjieh
Copy link

Any updates on this?

VSCode is not showing the computed type, it is just showing me the definition. This makes it really hard to develop when the types are complex.

@adi518
Copy link

adi518 commented Apr 1, 2022

This is incredibly painful. There's an extension that does exactly this, but it's half-arsed and stalls the editor.

@tehpsalmist
Copy link

https://stackoverflow.com/a/69223288/7872063 Current best hack-y workaround

@n8sabes
Copy link

n8sabes commented May 7, 2023

Using as const with different failure return types is a useful pattern. It would be high value to enable deeper insight beyond 160 characters to show all the possible return types.

The hack-y workaround above work, but requires applying the patch with every update. It would be easier with a script to re-apply the patch until a setting is added.

PLEASE PROVIDE THIS OR ALTERNATE METHOD OF VIEWING ALL RETURN VALUES.

@n8sabes
Copy link

n8sabes commented May 8, 2023

How to patch (on a Mac)

Known to work on VSCode Version: 1.79.0-insider (Universal). Inspect your tsserver.js file and adapt accordingly.

MANUAL PROCESS:

  1. Open this file in VSCode :
    /Applications/Visual\ Studio\ Code\.app/Contents/Resources/app/extensions/node_modules/typescript/lib/tsserver.js
  2. Search on: defaultMaximumTruncationLength =
  3. Replace the value 160 with 800.

AUTO-PATCH WITH SHELL SCRIPT:

#!/bin/zsh
file="/Applications/Visual Studio Code - Insiders.app/Contents/Resources/app/extensions/node_modules/typescript/lib/tsserver.js"
sed -i '' 's/defaultMaximumTruncationLength = 160;/defaultMaximumTruncationLength = 800;/g' "$file"

( Based on StackOverflow answer by Jeremy Caney / LoveriusB )

@doberkofler
Copy link

@n8sabes Thank you for the details. Should this not be made the default in vscode or at least be configurable?

@n8sabes
Copy link

n8sabes commented May 8, 2023

Hi @doberkofler, The CORRECT FIX is a true VSCode Setting from the team.

This hack is the best option I’ve found, but if you or anybody else knows of a better solution please post it.

I run VSCode Insiders, which updates frequently, so I wrote and shared the above auto-patch shell script.

If the code changes in future builds, the regex in this hack will need to be updated.

@leite08
Copy link

leite08 commented Jul 24, 2023

Tried the workarounds below but no luck:

  • edit tsserver.js's defaultMaximumTruncationLength to 800+;
  • add "noErrorTruncation": true to tsconfig.json.

The only one that "worked" is the Expand/ExpandAll type @lydell shared. I put it under quotes b/c changing our types to include it is not really a solution we're willing to adopt, so we keep it around as a dev env only tool to help debug complex types.

Would definitely be useful to have this as a VSCode, as a first-class-citizen config.

@MKRhere
Copy link
Author

MKRhere commented Jul 25, 2023

@leite08 truncation length is a fix to a different, but similar problem: when there are too many members in an object, and you get { ...18 more properties }, that setting forces TS to expand the list.

Meanwhile, this issue and the solution that worked for you are related to complex types not being resolved by TS/VSCode so we can see what it actually means.

This has been in the backlog for quite a while (it is now in the bottom 20% of issues by age), would be great if team took it up, but understandably the backlog is pretty long...

@vzakharov
Copy link

This is incredibly painful. There's an extension that does exactly this, but it's half-arsed and stalls the editor.

This one didn’t work for me (nothing shows up in the types panel), but that one seems to be doing fine: https://marketplace.visualstudio.com/items?itemName=mxsdev.typescript-explorer

Example screenshot:

Screenshot 2023-10-18 at 17 33 22

(I’m not affiliated in any way with the extension developer.)

@stefaanMLB
Copy link

I need exactly the opposite

async createPassword(login: string): Task<Doctor> {
}

becomes this useless lot in the tooltip, hiding the usefull infirmation that is in the jsdoc header

image
It would be nice if the tooltip type were overridden by the @returns jsdoc type indicator

@mjbvz
Copy link
Collaborator

mjbvz commented Dec 9, 2024

Tracked upstream in microsoft/TypeScript#59029

You can test it with TS 5.7+ today by setting: "typescript.experimental.expandableHover": true

@mjbvz mjbvz closed this as completed Dec 9, 2024
@mjbvz mjbvz added the upstream-issue-linked This is an upstream issue that has been reported upstream label Dec 9, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature-request Request for new features or functionality javascript JavaScript support issues typescript Typescript support issues upstream-issue-linked This is an upstream issue that has been reported upstream
Projects
None yet
Development

No branches or pull requests