Open MKRhere opened 4 years ago
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.
also looked into this. I've asked a question in stackoverflow. maybe we can get it from somewhere here in the vs code base?
@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.)
you are right. but this is still a workaround to this feature request. thanks! that helped me a lot!
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;
@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.
I have published a npm package for Expand
and ExpandDeep
based on the SO answer: https://www.npmjs.com/package/type-expand
It might be nice to gate this behind a modifier key, so we can toggle between expanded and unexpanded while the tooltip is up.
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.
This is incredibly painful. There's an extension that does exactly this, but it's half-arsed and stalls the editor.
https://stackoverflow.com/a/69223288/7872063 Current best hack-y workaround
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.
Known to work on VSCode Version: 1.79.0-insider (Universal). Inspect your tsserver.js
file and adapt accordingly.
MANUAL PROCESS:
/Applications/Visual\ Studio\ Code\.app/Contents/Resources/app/extensions/node_modules/typescript/lib/tsserver.js
defaultMaximumTruncationLength =
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 )
@n8sabes Thank you for the details. Should this not be made the default in vscode or at least be configurable?
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.
Tried the workarounds below but no luck:
tsserver.js
's defaultMaximumTruncationLength
to 800+;"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.
@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...
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:
(I’m not affiliated in any way with the extension developer.)
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
It would be nice if the tooltip type were overridden by the @returns
jsdoc type indicator
When working with complex types, I often encounter types like this:
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:
The impl of actual utils I'm using are inconsequential; it's the same if we'd used
Pick
,Omit
, orPartial
. 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 :)