Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

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

See original GitHub issue


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

Issue Analytics

  • State:open
  • Created 2 years ago
  • Reactions:17
  • Comments:7 (1 by maintainers)

github_iconTop GitHub Comments

essential-randomnesscommented, Nov 28, 2022

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.

Galbarcommented, Jun 9, 2022

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.

Read more comments on GitHub >

github_iconTop Results From Across the Web

Five ways to improve code with type aliases - Donny Wals
Today, I will show you five different applications of typealias that can dramatically improve your code when applied correctly. Let's dive right ...
Read more >
Type Errors - Pyre
If pyre was able to infer a type for the variable, it will emit this type in the error message. The fix is...
Read more >
US20060048095A1 - Local type alias inference system and method ...
The present invention discloses an improved system and method for specifying and compiling computer programs. Type aliases are introduced whose binding is ...
Read more >
Type Aliases vs Interfaces in TypeScript
A type alias is basically a name for any type. Type aliases can be used to represent not only primitives but also object...
Read more >
2338-type-alias-enum-variants - The Rust RFC Book
This RFC proposes to allow access to enum variants through type aliases. This enables better abstraction/information hiding by encapsulating enums in ...
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Post

No results found

github_iconTop Related Hashnode Post

No results found