Fixes #24

As mentioned in #23 some types will not resolve and this still happens with this tests, as of now im not aware on how i could write the test properly to fail when the type is not resolved, i tried to go on the .tree but felt that i would break the entire test if trying to change it by hand.

I also included the test mentioned in #25 so when custom depth is added this can be tested easily

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:

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!

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 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

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.

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.

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!

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!)

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>
)

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!

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).

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.

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.