A way to expand mapped types

I want to be able to expand mapped type in intellisense

Currently, mapped types is displayed directly with the mapper and original type, which is unhelpful as hell

With the ts 2.8 condition type, you can write more powerful declaration to map almost everything to correct type for you, but the ide simply show it is mapped, you don’t know what is it actually mapped to.

for example, in the above case, I have a mapper looks like

type Mapper<T> = {
    [K in keyof T]: 
        T[K] extends {type: SQL_ENUM<infer U>}? U:
        T[K] extends {type: SQL_ENUM<infer U>, allowNull: true}? U | undefined:
        
        T[K] extends {type: typeof Sequelize.DATE, allowNull: true}? Date | undefined:
        T[K] extends {type: typeof Sequelize.DATE}? Date:

        T[K] extends {type: typeof Sequelize.INTEGER, allowNull: true}? number | undefined:
        T[K] extends {type: typeof Sequelize.INTEGER}? number:

        // stop here, fon't let things goes too wrong
        T[K] extends {type: typeof Sequelize.ENUM}? never:

        T[K] extends {type: typeof Sequelize.STRING, allowNull: true}? string | undefined:
        T[K] extends {type: typeof Sequelize.STRING}? string:

        T[K] extends {type: typeof Sequelize.TEXT, allowNull: true}? string | undefined:
        T[K] extends {type: typeof Sequelize.TEXT}? string:

        T[K] extends {type: typeof Sequelize.BOOLEAN, allowNull: true}? boolean | undefined:
        T[K] extends {type: typeof Sequelize.BOOLEAN}? boolean:

        any
}

that will transform the decalration to a simple

interface session {
    token: string,
    userId: string,
    ip: string
}

But the ide won’t tell you anything, which is quite annoying

[jantimon]

This might look like the expand feature as described in #34944?

[weswigham]

@mjbvz could we perhaps expose consider exposing clickable “expando” ranges in quick info/signature help that fire a request to a new language server endpoint with a token associated with the range for expanded content for the range (and that expanded content may itself have more things which need expansion)? Off the top of my head, I can think of four places where this’d be useful:

1. Generics, aliases, and type queries. Click the a type reference to replace it with the structural decomposition (or conditional, union, whatever the underlying structure is) of the reference.

2. The any or ... we print for reverse mapped types. These types are limited in how much we print, as they have each property inferred on demand (as they each need to be mapped backwards through a mapped type). This is what happens when, for example, we infer the T in a Readonly<T> - we need to undo the readonlyness on whatever we find for T and we do that in a deferred fashion (since otherwise a circular type reference in the T would blow up, as we have no good name for our unmapped T to reference with). Being able to expand these one property at a time in the editor as needed would be great.

3. The any or ... we print on encountering circular referential local types. This happens when, for example, you have two mutually recursive functions that return one another. We actually type check this strongly, but both will just print as () => () => any or () => () => ... (as of yesterday) today, since we have no reference that we know will stick around with which to indicate the circularity.

4. The ... we print in the output when the type is truncated for being too long. Sometimes, even when a type is truncated, the part you care about isn’t in the beginning bit and you just wanna see more. Turning on noErrorTruncation works, but then you might always get huge types (and commensurately longer LS response times) - being able to expand little bits on demand could be a boon here.

cc @DanielRosenwasser and @RyanCavanaugh since I think we’ve mentioned this before.