What you’re not seeing is that TS is a structurally typed language, not a nominally typed language. Two type signatures defined in different places with a different name may be assignable to each other - so typescript usually has to deep-compare, recursively, the two types until a conflicting field is found.

So just hash the structures?

TypeScript team member here: the structures are arbitrarily deep and recursive. Also, as explained in a sibling comment, it's not just about type identity, but type assignability.

Hashing lets you know whether it's the same type or two different types, but you still need to look at the members to find out whether one is a subtype of the other.

> This statement makes me think... how come the TS compiler is not using something like a hash/map (object) of union members to basically ignore redundancy?

The trouble is the operation isn't "is X a member of Y", rather it's "does X match any values of Y according to predicate P."

You can break that out if you have knowledge of possible X's and P, as is the case with type matching.

Say we are checking G[] against {str, "foo literal", int[]}. I have no idea how TS implements these internally, but say the underlying type expressions are:

    [{head: String}, 
     {head: String, constraint:"foo literal"}, 
     {head: Array, element:{head: Integer}}]

And G[] is {head:Array, element: {head: Generic, name: "G"}}.

We could reasonably require that heads are all simple values, and then group types as such:

    {String: [{head: String},
              {head: String, constraint:"foo literal"}],
     Array: [{head: Array, element: {head: Integer}}]}

You'd still have to try to match that generic parameter against all the possible Arrays, but you could add more levels of hashing.

The downside is, of course, it's quite tricky to group types like this and prove that it returns the same results as checking all pairs, especially when you have a complex type system.