Type aliases not being resolved for some functions types

[gilbert]

TypeScript Version: 3.4.0-dev.20190310

Search Terms:

Resolve / flatten / simplify type aliases for function calls

resolve type aliases

Code

let subject = {a:1,b:2,c:3,d:4}

type thisResolves = Pick<typeof subject, 'a' | 'b'>

let thisDoesnt = pick(subject, ['a', 'b'])

declare function pick<T, K extends keyof T>(obj: T, keys: K[]): Pick<T,K>

Expected behavior:

The Quick Info type of thisDoesnt resolves to { a: number, b: number}

Actual behavior:

The Quick Info type of thisDoesnt resolves to Pick<{ a: number, b: number, c: number, d: number}, 'a' | 'b'>

Playground Link: here

Related Issues:

I've seen in other issues that type aliases are eagerly resolved (e.g. #13095 (comment) and #16798 (comment)). This is a case where that behavior is useful, since reading through a lot of Pick<Foo<Bar<... in VS Code makes it difficult to figure out the true source of a type error.

[dragomirtitian]

The two types are structurally equivalent, the only issue is with the quick info you see (as you already point out). Not sure what the heuristic is for when the type gets resolved or it is kept as is, but I have found the following Id type useful for expanding a type alias.

let subject = {a:1,b:2,c:3,d:4}

type thisResolves = Pick<typeof subject, 'a' | 'b'>

let thisDoesnt = pick(subject, ['a', 'b']) // also expanded now

declare function pick<T, K extends keyof T>(obj: T, keys: K[]): Id<Pick<T, K>>

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

I use it mostly for debugging complex types, and I do not guarantee it will not cause problems in some corner casses, but it might be a useful workaround in some scenarios.

[RyanCavanaugh]

So the difference here is that you're hovering over a type vs a value, and we are (for whatever reason) more eager in resolving through aliases in the type case than in the value case. If you wrote

type A = typeof thisDoesnt;

and hovered on A you'd see the "resolved" type.

Which of those is preferable is extremely situational and I'm not sure making a change here is guaranteed to be a net improvement over the status quo.

[gilbert]

Strange, the typeof trick isn't working in my project. I thought the playground link was a good minimal example, but my own case might have to do with types across modules or something.

Are there any current proposals to "suggest" to the TS compiler which aliases to collapse and which to retain?

[paldepind]

I have a problem related to this which is making some types in a project practially unreadable.

I'm using the following type Remap:

export type Remap<
  A extends Record<any, any>,
  B extends Record<any, keyof A>
> = { [K in keyof B]: A[B[K]] };

When Remap is used the type that is resolves/computes/reduces to is always much much smaller than the uncomputed version. Here is an example:

type Big = { a: number, b: number, c: string, d: number, e: number }

function f<A extends Record<string, keyof Big>(a: A): Remap<Big, A> {
    return 0 as any;
}

const a = f({q: "c"});

If I hover over a in an IDE I see the type Remap<Big, { q: "c"; }> when really it would have been much more useful to see { q: string }. If I write type A = typeof a; then that is what A becomes.

I understand that unfolding type definitions isn't always what one wants. But, I have a strong feeling that there is a better approach than what is currently done. Maybe just always select the shortest (measured in characters) option between fully computed and not at all computed?