Attempt to more-frequently use local aliases when printing out types

When a user imports a type alias like

// ./a.ts
export type Foo = number | string | symbol;

We should try to print out Foo in error messages like in

// ./b.ts
import { Foo } from "./a.js"

let x: Foo = true;

and in declaration emit like in

// ./c.ts
import { Foo } from "./a.js"

function f(x: Foo) {
  return x;
}

[AnyhowStep]

As long as the Identity<> trick doesn’t break, right?

https://github.com/microsoft/TypeScript/issues/34556

There are cases where Foo is actually a generic type. And Foo<T> is 100+ lines long because T is 100+ lines long.

But if Foo<T> is “expanded”, the expanded type could be like 5 lines.

The Identity<> trick forces TS to always expand the type, at the moment.

---

Pick and Omit suffer from this problem, too.

Pick<T, K>

If T is 100+ properties and K is 2 properties, the emit can be 100+ lines long. In such cases, I always tell people to write their own version of Pick and Omit using the Identity<> trick.

https://github.com/microsoft/TypeScript/issues/34793

---

I guess I should find/file a separate issue for this, and locate all the relevant issues. (Like a meta issue regarding type display?)

But it seems like TS doesn’t really give developers a way to explicitly control how they want a type to “expand” in emit/hover, at the moment.

To TS, as long as the types behave well, then all is good; it doesn’t matter if the type looks simple or complicated.

Except, to developers, if the type looks complicated/long/verbose, then it’s extra cognitive overhead. That, and hover and error messages tend to truncate long types.

---

I’m not sure how to phrase this properly.

I think it’s fine to have heuristics for TS to automatically determine how to “present” a type. Given a type, there could be a million different ways to express it syntactically.

However, there needs to be a way for a programmer to step in and say, “Your heuristics are bad.”, “Expand this type.”, “Don’t expand this type.”, “Use typeof x instead of X”, etc.

Because, sometimes, the 100+ line type is more readable than the 5 line type. Mostly, it’s the other way around. Sometimes, aliases are easier to understand. Other times, the full expanded type is easier. There’s no way an algorithm can display a type such that it’ll always be “easiest” to read. It’s rather subjective, I’ve found.

---

Also relevant, https://github.com/microsoft/TypeScript/issues/32977

[AnyhowStep]

The problem with that solution is that it does not help for .d.ts emit and error message elaboration.

Those 2 cases are the main motivators, for me.

See,

https://github.com/microsoft/TypeScript/issues/35654

https://github.com/microsoft/TypeScript/issues/34556

When .d.ts emit goes wrong and it emits too much, the emitted files become unreadable, or cause emit times to blow up

When it emits too little, it can also impact readability negatively, the compiler needs to put in more work to resolve the type for downstream consumers, increasing check times, causing earlier max depth errors, etc

Error elaborations are also affected by emit being too small, or too large