This is just a FYI but it might require a look into your code.
microsoft/TypeScript#55673
Note in the stack trace that this extension is referenced

Would be nice to show type arguments in descriptions. So, for example, the following:

Would display Promise<void> instead of Promise.

There should probably be a config option to toggle this feature, as well as a maximum length before going to ellipsis (e.g. Promise<...>.

From #18 (thanks to @Didas-git for the suggestion!)

For symbols defined with declare, the declaration is not included as a location, which prevents us from retrieving the jsdoc. For example, in the following, Button (which is defined with declare) will have no jsdoc.

import React from "react"
import { Button } from "@mui/material"

export const Component: React.FunctionComponent = () => (
    <Button>Button</Button>
)

Readonly arrays are treated as objects, rather than arrays.

Max recursion depth tree items should say "Max recursion exceeded" or something like that on hover, instead of just ellipses.

This will help users understand that this is not occurring due to an error.

Sometimes the bundle fails in vscode because an extraneous dependency (typescript) is require'd, but is not included in the bundle.

This can probably be accomplished with this eslint rule, but the vscode integration tests should 100% be using the bundled version rather than --extensionDevPath.

Currently, the extension window is empty when no type is selected. As was pointed out by a user, this can be pretty confusing.

One solution is to have placeholder text that simply indicates that the user needs to select a variable in order for anything to show up.

Config options are rather opaque in the settings ui at the moment, descriptions should help.

Thanks to @Didas-git for the suggestion!

The TypeInfo tree will be generated on every call to getQuickInfo on the typescript server. This can potentially cause enormous slowdowns on hovers in VSCode.

Ideally, the tsserver plugin would generate a type tree only upon a quick info call originating from the extension.

Sometimes, the getTypeFromTypeNode wrapper fails unexpectedly.

First, your extension here made making sense of a large enterprise code base much easier. Upon stumbling upon this extension, I have been able to better navigate and understand a very complicated codebase much easier.

That being said, I have one suggestion. With such a complex code base, I often ran over the default maxRecsionDepth of 6 and wonder why your extension failed show data. Only upon looking at your changelog was I able to see that this config was added.

IMO, this should be main option of changing the depth. I know there are risks with extension performance associated with giving this control over to the user but being able to configure this myself was very, very helpful.

Other than that, thank you for taking the time to develop this extension.

Hey,

I found your extension today and it is awesome! It is helping loads with Material UI (@mui) and it's convoluted types 😂.

Anyway, the search button doesn't seem to work or do anything really, I presume this isn't intentional?

Automate publish in prerelease.yml to the Open VSX registry and the VSCode marketplace.

While exploring complex types, I often create dummy types as a way to explore a certain part of the type in ts-type-explorer. For example, if I'm exploring this type:

type Context = InferContext<createContext>

I might want to explore Context['data']['user'] in more detail without hitting the recursion limit, so I'll do:

type Context = InferContext<createContext>
type Foo = Context['data']['user']

Instead, it would be nice if I could double-click the Context['data']['user'] node in the ts-type-explorer tree to "focus" it, making it the root of the tree.

Sometimes, like in the following map call, type arguments are simply not discovered.

const mapped = [1].map(x => x.toString())

Extension option to suppress non-critical error messages.

Type: Bug

This iextension is working fine in another project so I don't really know what the issue is with this one. But you could try cloning the Supafly remix starter at https://github.com/rphlmr/supa-fly-stack and follow all the steps to have it up and running.
Here's my package.json:

{
  "name": "youwish_app-a3a1",
  "private": true,
  "sideEffects": false,
  "scripts": {
    "build": "run-s build:*",
    "build:css": "npm run generate:css -- --minify",
    "build:remix": "remix build",
    "db:prepare-migration": "prisma migrate dev --create-only --skip-seed",
    "db:deploy-migration": "prisma migrate deploy",
    "dev": "run-p dev:*",
    "dev:css": "npm run generate:css -- --watch",
    "dev:remix": "remix dev",
    "format": "prettier --write .",
    "generate:css": "tailwindcss -o ./app/styles/tailwind.css",
    "lint": "eslint --cache --cache-location ./node_modules/.cache/eslint .",
    "setup": "run-s setup:db setup:seed",
    "setup:db": "prisma generate && prisma migrate deploy",
    "setup:seed": "prisma db seed",
    "start": "remix-serve build",
    "start:ci": "dotenv -- remix-serve build",
    "test": "vitest",
    "test:cov": "vitest --coverage",
    "test:e2e:dev": "start-server-and-test dev http://localhost:3000 'npx cypress open'",
    "pretest:e2e:run": "npm run build",
    "test:e2e:run": "dotenv -- cross-env PORT=8811 start-server-and-test http://localhost:8811 'npx cypress run'",
    "typecheck": "tsc -b && tsc -b cypress",
    "validate": "run-p \"test -- --run\" lint typecheck test:e2e:run"
  },
  "prettier": {
    "semi": false,
    "singleQuote": true,
    "trailingComma": "all",
    "printWidth": 180,
    "tabWidth": 2,
    "useTabs": false
  },
  "dependencies": {
    "@prisma/client": "^4.6.1",
    "@remix-run/node": "^1.12.0",
    "@remix-run/react": "^1.12.0",
    "@remix-run/serve": "^1.12.0",
    "@supabase/supabase-js": "^2.2.3",
    "cookie": "^0.5.0",
    "i18next": "^21.9.1",
    "i18next-browser-languagedetector": "^6.1.5",
    "i18next-fs-backend": "^1.1.5",
    "i18next-http-backend": "^1.4.1",
    "isbot": "^3.5.0",
    "react": "^18.2.0",
    "react-dom": "^18.2.0",
    "react-i18next": "^11.18.5",
    "react-zorm": "^0.6.1",
    "remix-i18next": "^4.1.1",
    "remix-typedjson": "^0.1.7",
    "tailwind-merge": "^1.8.0",
    "zod": "^3.19.1"
  },
  "devDependencies": {
    "@faker-js/faker": "^7.6.0",
    "@remix-run/dev": "^1.12.0",
    "@remix-run/eslint-config": "^1.12.0",
    "@tailwindcss/aspect-ratio": "^0.4.2",
    "@tailwindcss/forms": "^0.5.3",
    "@tailwindcss/line-clamp": "^0.4.2",
    "@tailwindcss/typography": "^0.5.8",
    "@testing-library/cypress": "^8.0.3",
    "@testing-library/jest-dom": "^5.16.5",
    "@testing-library/react": "^13.4.0",
    "@testing-library/user-event": "^14.4.3",
    "@types/i18next-fs-backend": "^1.1.2",
    "@types/react": "^18.0.21",
    "@types/react-dom": "^18.0.6",
    "@vitejs/plugin-react": "^2.1.0",
    "@vitest/coverage-c8": "^0.24.3",
    "cross-env": "^7.0.3",
    "cypress": "^10.10.0",
    "dotenv-cli": "^6.0.0",
    "eslint": "^8.28.0",
    "eslint-config-prettier": "^8.5.0",
    "eslint-plugin-tailwindcss": "^3.7.0",
    "happy-dom": "^7.6.0",
    "msw": "^0.49.0",
    "npm-run-all": "^4.1.5",
    "prettier": "2.7.1",
    "prettier-plugin-tailwindcss": "^0.1.13",
    "prisma": "^4.6.1",
    "prisma-json-schema-generator": "^3.1.2",
    "prisma-zod-generator": "^0.2.0",
    "start-server-and-test": "^1.14.0",
    "tailwind-scrollbar": "^2.0.1",
    "tailwindcss": "^3.2.4",
    "ts-node": "^10.9.1",
    "tsconfig-paths": "^4.1.0",
    "typescript": "^4.8.4",
    "vite-tsconfig-paths": "^3.5.2",
    "vitest": "^0.24.3"
  },
  "engines": {
    "node": ">=16"
  },
  "prisma": {
    "schema": "app/database/schema.prisma",
    "seed": "ts-node --require tsconfig-paths/register app/database/seed.server.ts"
  }
}

Extension version: 0.4.0
VS Code version: Code 1.76.0 (92da9481c0904c6adfe372c12da3b7748d74bdcb, 2023-03-01T10:23:06.752Z)
OS version: Darwin arm64 22.3.0
Modes:
Sandboxed: No

vsliv368:30146709
vsreu685:30147344
python383cf:30185419
vspor879:30202332
vspor708:30202333
vspor363:30204092
vstes627:30244334
vslsvsres303:30308271
pythonvspyl392:30443607
vserr242cf:30382550
pythontb:30283811
vsjup518:30340749
pythonptprofiler:30281270
vsdfh931cf:30280410
vshan820:30294714
vstes263:30335439
vscoreces:30445986
pythondataviewer:30285071
vscod805cf:30301675
binariesv615:30325510
bridge0708:30335490
bridge0723:30353136
cmake_vspar411:30581797
vsaa593cf:30376535
pythonvs932:30410667
cppdebug:30492333
vscaat:30438848
vsclangdf:30486550
c4g48928:30535728
dsvsc012:30540252
pynewvextcfv2:30681851
azure-dev_surveyone:30548225
pyindex848:30662994
nodejswelcome1cf:30587006
2e4cg342:30602488
pyind779:30671433
f6dab269:30613381
pythonsymbol12:30671437
a9j8j154:30646983
vscodedisable:30660115
pythonb192cf:30669361
funwalk2:30682974

Sometimes when exploring the type tree, particularly in function signatures, max recursion occurs unexpectedly.

TODO: update with examples.

This would be a huge boon for large types that I want to include in reference documentation

Is it possible to add the info to the hover peek type info popup?

Modules currently aren't directly supported, so they are interpreted as object.

This works well sometimes, but if you try to generate a type tree for a massive source file (like typescript or react) it sometimes throws an error. This should probably be investigated/fixed.

(The above is actually due to #14)

The implementation for modules, if feasible, should be similar to that of #6.

Might be nice to allow more complex filtering/sorting options.

For example, sort by type kind, sort alphabetically, filter non-methods, etc.

One challenge with doing this is finding a way to make it feel natural using the menu options provided by the Extension API. Not sure if there's actually a way to have, for example, a checkmark on a menu option.

Trying to load the "react" module results in an error.

Specifically, it fails to load "ReactFragment" from line 228, character 9.

What's very strange about this issue is that it only seems to occur in vscode, but I cannot currently replicate it with tests.

Include "readonly" in the description for properties/arrays

Volar is used by Vue, Svelte, and Astro to help bridge the gap between Typescript and their own file types. Volar is currently undergoing a rewrite at the moment, once they're done, I hope to see this extension support these incredible ecosystems.

Add a collapse all button, like in the other views.

While exploring complex types, I often hit the recursion limit, and need to perform the workaround I described in #35 of creating a dummy type.

Would it be possible to lazily evaluate types as the user expands nodes in the ts-type-explorer tree, and get rid of the recursion limit?

For example, when you first open ts-type-explorer, only the first level of the tree is visible. Rather than evaluating all branches of the tree until the recursion limit is reached, could you only evaluate the visible nodes? That way the user should be able to continue expanding nodes without hitting an arbitrary depth limit.

Hi! I noticed that extension makes ts requests before view is opened, which I don't really like.

I noticed that extension has these activation events:

onLanguage:typescript
onLanguage:javascript
onLanguage:typescriptreact
onLanguage:javascriptreact

But why they needed?

I think you can either remove these activation events or make view initialize lazily by using treeDataProvider.onLoad callback eg.

The current tests for mapped types are extremely simple, and we should probably have more.

Thanks to @Didas-git for pointing this out!

I suddenly started having my intellisense hang indefinitely on a cypress project, and after an extension bisect found ts-type-explorer was the issue. Thankfully I solved the problem by lowering the max recursion depth to 4. I figured the type-structure must have branched out too rapidly, but it made me think there must be a better way to handle recusion calculation overload. My suggestions are:

1. Only explore and find the types when the user expands that part of the type explorer.

   • There is no point collecting n-levels depth of type information if the nodes are collapsed, and this approach would prevent the exponential slowdown as depth increases. It would also remove the need to set a hard cap on the depth explorable.
   • EDIT: I do see that another user asked about this issue, and that the answer was: it was already implemented on some, but tricky to implement on specific types of types

2. Allow the user to set a calculation timeout at which point to stop further recursing.

   • This could be used instead of a hard depth stop, particularly if the approach was to calculate level n of recursion for the entire tree, before level n+1. This would fit better with a variety of codebase sizes and complexities, and also let the user know what was going wrong if their computer had ground to a halt.

Also to note - I was having my intellisense hang even when I had not focused the type-explorer tab. This feels like a mis-step, I wouldn't mind a delay when opening the tab, if it meant a more performant codebase the rest of the time. A spinner and a "stop calculation" button would be good UI additions too.

Since the plugin now overrides completions, plugins which interface with completions, such as the svelte plugin, are incompatible, and can cause errors retrieving info.

There's probably a few ways to approach solving this, like returning dummy info, or forcing extension load order somehow (by e.g. requiring the svelte extension as a dependency, if VSCode provides a way to do that).

Type: Bug

It seems that activating this extension causes CPU usage to be high and also makes Command+space suggestion very, very slow.

I'm working on quite a bit TS project, with the @effect library.

[Edit] Sorry, I reported this from VSCode and thought it'd go privately to the extension owner, did not understand it'd create an issue in here. Feel free to close this.

Extension version: 0.4.2
VS Code version: Code 1.84.2 (1a5daa3a0231a0fbba4f14db7ec463cf99d7768e, 2023-11-09T10:52:57.054Z)
OS version: Darwin arm64 23.0.0
Modes:

vsliv368:30146709
vspor879:30202332
vspor708:30202333
vspor363:30204092
vscorecescf:30445987
vscod805cf:30301675
binariesv615:30325510
vsaa593:30376534
py29gd2263:30899288
vscaat:30438848
c4g48928:30535728
azure-dev_surveyone:30548225
a9j8j154:30646983
962ge761:30959799
pythongtdpath:30769146
welcomedialog:30910333
pythonidxpt:30866567
pythonnoceb:30805159
asynctok:30898717
pythontestfixt:30902429
pythonregdiag2:30936856
pyreplss1:30897532
pythonmypyd1:30879173
pythoncet0:30885854
pythontbext0:30879054
accentitlementsc:30887149
dsvsc016:30899300
dsvsc017:30899301
dsvsc018:30899302
bf62j303:30959262
cppperfcontrol:30979541
d34g3935:30971562
bg6jg535:30979843
dsvsc020:30976470
jchc7451:30973076

Type: Bug

This extension appears to greatly slow down TS autocomplete even when the extension tab is not focused. It creates a big drag on editing speed. Hopefully the extension can be updated so that it does nothing unless it's the active panel.

Extension version: 0.4.2
VS Code version: Code 1.79.2 (695af097c7bd098fbf017ce3ac85e09bbc5dda06, 2023-06-14T08:58:33.551Z)
OS version: Darwin arm64 22.5.0
Modes:

Right now, namespaces are treated as object. One consequence of this is that types in namespaces are not presented in the type tree, since they are not "properties" on the namespace's object type, and so aren't returned from getProperties().

Namespaces should be supported as their own "kind," like interfaces and objects.

Some types have show internal symbols such as the following:

Ideally, these should be hidden by default.

From #18 (thanks to @Didas-git for the suggestion!)

Currently, the internal recursion depth is capped at 6, which makes cases like this one cause max recursion nodes.

This depth number should be user-configurable.

Thanks to @Didas-git for the example and suggestion!

Currently one of the major problems is that Promises are shown as an object type and do not give you the return type upfront.
My idea would be to use the <type arguments> to defined the promise type since it contains the proper type of the promise.

Another issue is that promises show a rather useless tag when looking into them

I think the result in the picture above is wrong.

Hi,

I love this extension.
Can you please provide a functionality to copy the typescript type tree as a interface.
Ex: I right click on the selected type from the tree and copy as interface and then If I paste it in a editor it generates me the typescript interface for the selected type.

In many circumstances, type parameters are not resolved, even if type arguments are. For example:

declare function name(): Promise<void>;

The return type here will show void as a type argument, but will not display T, the relevant type parameter.

Thanks to @Didas-git for pointing this out!

Might be nice to have 1-2 extra windows, to allow for something like having multiple locked types.

I'd like to see "top to bottom hierachy" of classes, as you can see for example for Java in the Eclipse.

It is useful to know, which subtypes are declared for current type. The tree levels could be populated lazily for better performance. Is this is possible?

Would be nice to support type predicates. Right now, they just appear as boolean.

Just want to say a big thanks for your extension - it's been a real life-saver while debugging complex types!

I'm a Neovim user, but I've got a VSCode instance running in the background just for your extension and a small handful of others. It would be amazing to see your extension as a Neovim plugin. I see from your dotfiles that you're a Neovim user as well, so I thought you might also be interested.

Considering the way you've modularized the extension, it seems creating a Neovim front-end should be pretty straightforward. What do you think? Perhaps using sidebar.nvim could make the process a bit easier?

Really looking forward to what comes next.

Trying to install this plugin/extension on Remote SSH VSCode instance/environment - freezes on "Installing" step, and never be endeded, if target host could't have free acccess to web;

Error while installing 'mxsdev.typescript-explorer' extension in the remote server. connect EACCES 64:ff9b::d6b:6af:443

Many other plugins do not have such a need/need when installing, getting everything they need from the user host 🤷‍♂️
May be possible to include dependency in package of plugin?

2024-04-08 15:15:39.491 [info] Started local extension host with pid 75330.
2024-04-08 15:15:39.680 [info] Invoking resolveAuthority(ssh-remote)...
2024-04-08 15:15:39.680 [info] [LocalProcess0][resolveAuthority(ssh-remote,1)][0ms] obtaining proxy...
2024-04-08 15:15:39.681 [info] [LocalProcess0][resolveAuthority(ssh-remote,1)][0ms] invoking...
2024-04-08 15:15:39.796 [info] [LocalProcess0][resolveAuthority(ssh-remote,1)][115ms] returned Managed(1)
2024-04-08 15:15:39.796 [info] resolveAuthority(ssh-remote) returned 'Managed(1)' after 115 ms
2024-04-08 15:15:39.796 [info] Creating a socket (renderer-Management-ffbbb26e-8e6e-41b4-b274-c3e5ffaca6ad)...
2024-04-08 15:15:39.796 [info] Creating a socket (renderer-ExtensionHost-1ec1bb1e-86d2-4222-b96a-565893d3b5e6)...
2024-04-08 15:15:39.834 [info] Creating a socket (renderer-ExtensionHost-1ec1bb1e-86d2-4222-b96a-565893d3b5e6) was successful after 38 ms.
2024-04-08 15:15:39.835 [info] Creating a socket (renderer-Management-ffbbb26e-8e6e-41b4-b274-c3e5ffaca6ad) was successful after 39 ms.
2024-04-08 15:15:43.076 [info] [perf] Render performance baseline is 18ms
2024-04-08 15:15:45.066 [info] Extension host (Remote) is unresponsive.
2024-04-08 15:15:47.091 [info] Extension host (Remote) is responsive.
2024-04-08 15:20:57.899 [error] Unable to resolve resource search-editor:#0.10431004774635366: Error: Unable to resolve resource search-editor:#0.10431004774635366
    at a.r (vscode-file://vscode-app/Applications/Visual%20Studio%20Code.app/Contents/Resources/app/out/vs/workbench/workbench.desktop.main.js:2412:25870)
    at a.r (vscode-file://vscode-app/Applications/Visual%20Studio%20Code.app/Contents/Resources/app/out/vs/workbench/workbench.desktop.main.js:2412:25856)
    at async C.acquire (vscode-file://vscode-app/Applications/Visual%20Studio%20Code.app/Contents/Resources/app/out/vs/workbench/workbench.desktop.main.js:37:3392)
    at async u.createModelReference (vscode-file://vscode-app/Applications/Visual%20Studio%20Code.app/Contents/Resources/app/out/vs/workbench/workbench.desktop.main.js:2412:27205)
    at async a (vscode-file://vscode-app/Applications/Visual%20Studio%20Code.app/Contents/Resources/app/out/vs/workbench/workbench.desktop.main.js:769:76506)
2024-04-08 17:51:15.404 [error] Error while installing 'mxsdev.typescript-explorer' extension in the remote server. connect EACCES 64:ff9b::d6b:6af:443
2024-04-08 17:51:15.406 [info] Downloading the 'mxsdev.typescript-explorer' extension locally and install
2024-04-08 17:51:17.087 [info] Downloaded extension: mxsdev.typescript-explorer /Users/ruvata34/Library/Application Support/Code/CachedExtensionVSIXs/mxsdev.typescript-explorer-0.4.2
2024-04-08 18:06:24.063 [info] Started local extension host with pid 79850.
2024-04-08 18:06:24.271 [info] Invoking resolveAuthority(ssh-remote)...
2024-04-08 18:06:24.271 [info] [LocalProcess0][resolveAuthority(ssh-remote,1)][0ms] obtaining proxy...
2024-04-08 18:06:24.272 [info] [LocalProcess0][resolveAuthority(ssh-remote,1)][0ms] invoking...
2024-04-08 18:06:24.385 [info] [LocalProcess0][resolveAuthority(ssh-remote,1)][114ms] returned Managed(1)
2024-04-08 18:06:24.385 [info] resolveAuthority(ssh-remote) returned 'Managed(1)' after 114 ms
2024-04-08 18:06:24.386 [info] Creating a socket (renderer-Management-efb01497-b662-4749-b71c-8c3bc26793e2)...
2024-04-08 18:06:24.386 [info] Creating a socket (renderer-ExtensionHost-1af97ced-73e4-4a23-8d3c-2cc13b885d30)...
2024-04-08 18:06:24.428 [info] Creating a socket (renderer-Management-efb01497-b662-4749-b71c-8c3bc26793e2) was successful after 42 ms.
2024-04-08 18:06:24.429 [info] Creating a socket (renderer-ExtensionHost-1af97ced-73e4-4a23-8d3c-2cc13b885d30) was successful after 43 ms.
2024-04-08 18:06:27.416 [info] [perf] Render performance baseline is 16ms
2024-04-08 18:06:29.674 [info] Extension host (Remote) is unresponsive.
2024-04-08 18:06:31.041 [info] Extension host (Remote) is responsive.
2024-04-08 18:07:27.872 [error] Error while installing 'mxsdev.typescript-explorer' extension in the remote server. connect EACCES 64:ff9b::d6b:6af:443

Currently, union types are kept as union types, with their constituent parts recursively merged. This is pretty much the best you could hope to do, although there are a few things you can do:

• Distribute intersections over unions
• Extract the "greatest common denominator" from the union

The first example means, for example, {a: any} & ({b: any} | {c: any}) -> {a: any, b: any} | {a: any, c: any}. The second is the exact reverse of this.

The most useful is probably the second, i.e., extracting the common factors out of the union, since this leaves the union members as small as possible.

The problem of finding a gcd out of some objects, however, is kind of non-trivial, because there is some serious requisite recursive logic. For example:

type t = 
  |{
    a: any,
    b: {
        x: any,
        y: any,
    }
  }
  |{
    c: any,
    b: {
        y: any,
        z: any
    }
  }

would need to be converted to:

type t =
  {
    b: {
      y: any
    }
  } & (
    |{
      a: any,
      b: {
        x: any
      }
    }
    |{
      c: any,
      b: {
        z: any
      }
    }
  )

The recursive logic is manageable, however the problem really here is type comparison. For example, in the above example, we have to determine that b.y is equal in every element of the union. And I'm not sure whether it's possible to compare types like this using only externally exported methods from the typeChecker.

As of now running tests on the lib will always result in 2 errors.
This errors come from the module.ts file and are a result of how the tests are writen, i dont think this is a huge issue but at least one that should be mentioned on the contributing.md file.

Error:

Example:

interface FieldVals {
    string: string;
    number: number
}

type FieldFormat = Record<string, keyof FieldVals>

type MapField<T extends FieldFormat> = {
    [K in keyof T]: FieldVals[T[K]]
}

declare function createField<T extends FieldFormat>(data: T): MapField<T>

const f = createField({a: "string"})

f.a

f.a in the extension will resolve to the symbol a which is of type "string", rather than following the resolution through to FieldVals, which should result in type string.

Thanks to @Didas-git for reporting this/providing the example!

First off. Thanks for the awesome extension.

I would love to be able to compare two types kind of like vscode's "select for compare" and "compare with selected" functionality for files. Is anything like that possible/in scope?