Difference between intersection and merged types `{ foo } & { bar }` and `{ foo, bar }` in TypeScript

Question

Consider the types FooBar1 and FooBar2 defined as follows:

type Foo = { foo: string };
type Bar = { bar: number };
type FooBar1 = Foo & Bar;
type FooBar2 = { foo: string; bar: number };

Question: What is the difference between FooBar1 and FooBar2?

---

My attempt / research:

• They are bidirectionally assignable to each other! (checked manually and with tsd - see here)
• Still, they are not identical to each other! (checked with tsd - see here)
• VSCode's intellisense does not collapse { foo } & { bar } automatically into { foo, bar }, while it does collapse other complex types to simpler forms, such as NonNullable<string | undefined> to string:

// |------------------------------------------------------------|
// | let x: {                                                   |
// |     a: string;                                             |
// | } & {                                                      |
// |     b: string;                                             |
// | }                                                          |
// | -----------------------------------------------------------|
//  ^
//  | When hovering `x` here:
//  |
let x: { a: string } & { b: string };

---

Edit: Difference between extending and intersecting interfaces in TypeScript? has been suggested as a duplicate but I disagree. Instead of comparing an intersection to the extension of an interface, I am comparing an intersection to another raw type, no interfaces or extensions involved.

Answer 1

In your example, we can say that FooBar1 and FooBar2 are equal. And we can indeed prove that:

type Equals<A, B> =
    A extends B
    ? B extends A
      ? true
      : false
    : false

type test0 = Equals<{a: 1} & {b: 2}, {a: 1, b: 2}> // true

But for a general answer, we can only say that they are not always equal. Why? Because intersections can resolve to never in some cases. If ts finds an intersection to be valid, it proceeds with it, otherwise returns never.

import {O} from "ts-toolbelt"

type O1 = {a: 1, b: 2}
type O2 = {a: 1} & {b: 2}       // intersects properly
type O3 = {a: 1, b: 2} & {b: 3} // resolved to `never`

type test0 = Equals<O1, O2>
// true

type test1 = O.Merge<{a: 1, b: 2}, {b: 3, c: 4}>
// {a: 1, b: 2, c: 4}

Here type O3 resolved to never because b is 3 and it cannot overlap with 2. Let's change our example to show that an intersection would work if you had:

import {A} from "ts-toolbelt"

type O4 = A.Compute<{a: 1, b: number} & {b: 2}> // {a: 1, b: 2}
type O5 = A.Compute<{a: 1, b: 2} & {b: number}> // {a: 1, b: 2}

This example also highlights how intersections work -- like union intersections. TypeScript will go over all the property types and intersect them. We've forced TypeScript to compute the result of the intersection with A.Compute.

In short, if ts cannot overlap ALL OF the members, then the product of that intersection is never. For this reason, it might not be suitable as a merging tool:

type O3 = {a: 1, b: 2} & {b: 3} // resolved to `never`

So remember, & is not a merging tool. A & B is only equal to {...A, ...B} only if they have keys that do not overlap. If you need a merging type, use O.Merge.