Improve type readability (fix type alias propagation, allow aliasing inferred types)

[martaver]

Suggestion

🔍 Search Terms

preserve type aliases,inferred types,type names,readability,type expansion

✅ Viability Checklist

My suggestion meets these guidelines:

• [*] This wouldn't be a breaking change in existing TypeScript/JavaScript code
• [*] This wouldn't change the runtime behavior of existing JavaScript code
• [*] This could be implemented without emitting different JS based on the types of the expressions
• [*] This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)
• [*] This feature would agree with the rest of TypeScript's Design Goals.

⭐ Suggestion

One thing that makes working with Typescript's type system occasionally hopeless is when cumulative inferred types are displayed in type expansion and 'pollute' the information in quick info or errors.

So the proposal is two fold:

1. Fix type expansion so that the names of type aliases are preferred over their expanded inferred types wherever a type alias is available.
2. Add syntax that allows us to 'alias'/name inferred types and allow those alias names to carry through type expansion.

📃 Motivating Example

With any kind of sophisticated typing, we quickly end up with error messages and parameter info that takes multiple seconds to load, and shows a truncated mess of type syntax. Worse, the expansion of these inferred types accumulates and adversely affects any code that touches them.

Typescript fails us in two distinct areas with regard to type expansion, and the culprit seems to be inferred types...

1. Typescript doesn't always respect type aliases, even when they are explicitly provided

E.g. First, what works:

// Let's start with a contrived mapped type:

type Mapped<T> = {
  [P in keyof T]: never;
};

// And a generic function that takes an argument and returns the mapped type of it.

function map<T>(value: T): Mapped<T> {
  return {} as never;
}

// Create a Person via inference
const p = {age: 5, name: 'Bobby'};

// And quick info on 'inferred' displays: Mapped<{age: number, name: string}>
const inferred = map(p);

// Let's clean up the inferred type by defining a type alias.
type Person = {age: number; name: string};

// Now quick info on 'named' shows: Mapped<Person>
const named = map({age: 5, name: 'Bobby'} as Person);

So far, so good. The rule seems to be that if we explicitly alias a type, Typescript will use that name and terminate expansion.

But this rule gets broken when there is logic to the type alias.

// Use `io-ts` as an example and declare runtime types/validators like so:

import * as t from 'io-ts';

const Person = t.type({
  name: t.string,
  age: t.number,
});

// And infer the underlying data type from it...
type Person = t.TypeOf<typeof Person>;

// Now, let's put them through the same Mapped type and map function...

// We use the type alias 'Person' in the same manner to try to 'name' the type, but...
const named = map({age: 5, name: 'Bobby'} as Person);

// Quick info on 'named' is: Mapped<{name: string, age: number}> not Mapped<Person>

You could argue that this is handy, but the consequences of this deviation from the rule means that all other types referencing this one will repeat the full expansion.

2. There is no way to name an inferred type

There is also a scenario where fully expanded inferred types are unavoidable. More specifically, where there is no way to explicitly specify a type alias whose name should be displayed. E.g.

// Let's return to our Person type and try some composition:

const Family = t.type({
  mother: Person,
  father: Person,
  child: Person,
});

// The type of 'Family' is:  t.TypeC<{mother: t.TypeC<{name: t.StringC, age: t.NumberC}>, father: t.TypeC<{name: t.StringC, age: t.NumberC}>, child: t.TypeC<{name: t.StringC, age: t.NumberC}>}>

That's already pretty out of hand. All we would need to know, ideally, is something like (pseudocode) t.TypeC<{mother: Person, father: Person, child: Person}>.

But since the type of Person is inferred from the function's return type, we don't get a chance to create a type alias for it. In fact, that's the reason we're able to declare a type alias of the same name for the underlying data type.

So wherever we use the Person instance, we're now stuck with a fully expanded inferred type. If we were able to provide Typescript with an alias for the inferred type, we could escape expansion and clean up type expansions everywhere.

Proposed as type syntax

Such syntax could work like this:

// Combining the syntax for type assertion and type alias declaration:
const Person = t.type({
  name: t.string,
  age: t.number,
}) as type PersonType;

So that Family would then display: t.TypeC<{mother: PersonType, father: PersonType, child: PersonType}>

Since the above kind of factory that returns an inferred type is a common pattern, it could also be shorthanded like this:

const type PersonType = t.type({
  name: t.string,
  age: t.number,
});

...so that the name of the variable would double as the name of the type alias.

There could even be syntax that is used upstream by the function returning the inferred type...

function map<T>(value: T): Mapped<T> as type new {
   return {} as never;
}

// Here, the type of `MyMap` is `MyMap` (it gets aliased by default with the same name).
const MyMap = map({ age: 22, name: 'Bobby});

The MyMap alias expanded is Mapped<{ age: number, name: string }>

// We could also allow for when wrapping is needed...
function get<T>(value: T): Wrapper<T as type new> {
   return {} as never;
}

// Here Person instance is typed as Wrapped<Person>, where Person is { age: number, name: string }
const Person = get({ age: 22, name: 'Bobby' })

💻 Use Cases

I think I've covered quite specific use cases in my motivating example.

Leveraging type inference to construct sophisticated types is common enough now that we should pay particular attention to developer experience for type systems.

These two changes would especially allow both developers and library authors to have better control over the types their code emits to intellisense and allow them to craft an improved developer experience.

Specifically, we could use libraries like io-ts and zod without polluting our type intellisense.

[Andarist]

This could be super helpful for some crazy generic code in some of the libraries. I imagine if we could use template literals as the "dynamic" type name this could be even more useful.

[Galbar]

This would be great. I have a generic type that turns classes to plain interfaces (useful to work with the library class-transformer). a type that could be Plain<Chair> turns into a horribly long mapped type that, as it is so big, it ends up being unhelpful.

[essential-randomness]

This would be incredibly helpful. Typescript is great to onboard newcomers to projects, but complex type expansions unfortunately end up scaring many junior programmers, even when the types themselves would be easily readable with a system like this.

[martaver]

The thing is that the Typescript compiler has been architected to describe types in full semantic accuracy, rather than communicate types to developers with full clarity. If we had a way to to provide names to inferred types, then we could communicate a developer's intent far more clearly.

In languages like C#, types come first for better or worse, so types become a defacto channel for developers to convey their intent. Developers spend proportionally more time thinking about type names and documenting them.

Such a shift would only benefit the Typescript ecosystem.

[geoffreytools]

I often have the opposite problem and would prefer to read { [K in keyof Person]: never } or even { age: never, name: never } over Mapped<Person> because those type transformers stack up and at some point you don't know anymore which type that mess computes to. Additionally, when you reach that point, utils such as Compute from ts-toolbelt no longer work and just add to the stack.

I agree that the problem identified in the OP is real but I wanted to point out that it's one end of a spectrum, and I would rather have a language server option like displayMode: 'preferAliases' | 'preferExpansion' I could switch on and off, or maybe that compiler option could come in addition to this feature in order to counterbalance.

I also want to add that this piece of syntax would be devoid of semantic value, which on top of being a little weird in a type system would add bloat to TS which is already extremely verbose when types get complex.

My final observation would be that TS is not a semantic tool: it's a programming language to hack types on top of unruly Javascript. I understand that one would prefer it to be differently, but that way of thinking caused me the greatest pain when I picked up the language. TS is not Haskell or whatnot, it looks imperative because it is.

[martaver]

Obviously it's not something that fits all scenarios... it'd primarily be a syntax that API developers could opt-in to in order to make their APIs clearer at their discretion. But it could also be easily utilised by the consumer of the API to tidy up returned types.

You're right though, I think typescript is in over its head already. We have to be careful that new features actually improve the development experience.

[essential-randomness]

Would it be possible to develop this as an extension to Intellisense(?) or at least VSCode so that it's possible to toggle between the two views? I don't know whether anything would be required from Typescript itself for that.

[ddurschlag]

I don't think the syntax changes are needed, but the better alias inference would be great. Here's a minimal example (notably, this has no usage of libraries like io-ts):

type RawNumArray = number[];                                    // number[]: good!
type RawNumMatrix = Array<RawNumArray>;                         // RawNumArray[]: good!

type InferNumArray = [number[]] extends [infer T] ? T : never;  // number[]: good!
type InferNumMatrix = Array<InferNumArray>;                     // number[][]: Not good :(

This shows two aliases that resolve to the same type, but only one of them is compatible with the alias name preservation work done in #42149 and #42284 . I believe the issue is specific to type aliases that infer a non-primitive type (hence my use of number[] instead of number in this example).

Outside the language level, it would be great if at the language server level types (aliases and otherwise) could be viewed as an expandable tree. That would hopefully be a happy medium for both the use cases suggeted by @martaver and @geoffreytools .