A way to expand mapped types

[mmis1000]

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

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

[jantimon]

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

[akutruff]

I just ran into this myself setting up similar code. I have a lot of conditional and mapped types that work wonderfully, but they unfortunately render intellisense unusable.

Intellisense

const Person: t.TsTypeToObjType<MapPropDefinitionsToTsTypes<MapPropDefinitionsToTsOptionalProperties<t.MapTsPropertiesToPropDefinitions<MapPropDefinitionsToTsTypes<MapPropDefinitionsToTsOptionalProperties<MapObjectDefParamsToPropDefinitions<{
    type: t.Type<"string">;
}>>> & MapPropDefinitionsToTsTypes<...>, never>>> & MapPropDefinitionsToTsTypes<...>>

type Person = {
    type: LiteralType<"Person">;
    name: Type<"string">;
    age: Type<"number">;
}

[dragomirtitian]

@akutruff You can use an Id type to expand out the properties of a type alias (type Id<T> = {} & { [P in keyof T]: T[P} } ).

[akutruff]

@dragomirtitian

@akutruff You can use an Id type to expand out the properties of a type alias (type Id<T> = {} & { [P in keyof T]: T[P} } ).

Thanks for the suggestion. Unfortunately that didn't solve the problem. Only one property became simplified, but otherwise, it still has expanded noise.

Edit: From your suggestion, I was able to find another thread #22575 (comment) with a similar approach. In my case, I have recursive types, and that was causing the issue! Here is a modified version that does trick, but it runs into the issue with potentially infinite recursion. #34933 (comment)

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

[martaver]

I believe most of the pain in intellisense with regards to mapped types is because they're often passed inferred types that have no better name than their expanded form. Ordinarily, Typescript should display a type alias's name wherever possible, e.g. Mapped<Person>, however if Person has any logic to it, TS will instead display the fully expanded type, even if the 'Person' alias is explicitly passed.

There's also currently no way in Typescript to provide a name for an inferred type.

If the above problem were fixed and we were able to name inferred types, then we would be able to architect types whose naming actually communicates intent to developers clearly. I believe these would also provide natural points in intellisense where a developer could opt to 'step into' type expansion.

I detail the problem and make a proposal for new syntax to name inferred types here:
#45954