Typescript, merge object types?

Question

Is it possible to merge the props of two generic object types? I have a function similar to this:

function foo(a: A         


        

Answer 1

The intersection type produced by the TypeScript standard library definition of Object.assign() is an approximation that doesn't properly represent what happens if a later argument has a property with the same name as an earlier argument. Until very recently, though, this was the best you could do in TypeScript's type system.

Starting with the introduction of conditional types in TypeScript 2.8, however, there are closer approximations available to you. One such improvement is to use the type function Spread defined here, like this:

// Names of properties in T with types that include undefined
type OptionalPropertyNames =
  { [K in keyof T]: undefined extends T[K] ? K : never }[keyof T];

// Common properties from L and R with undefined in R[K] replaced by type in L[K]
type SpreadProperties =
  { [P in K]: L[P] | Exclude };

type Id = {[K in keyof T]: T[K]} // see note at bottom*

// Type of { ...L, ...R }
type Spread = Id<
  // Properties in L that don't exist in R
  & Pick>
  // Properties in R with types that exclude undefined
  & Pick>>
  // Properties in R, with types that include undefined, that don't exist in L
  & Pick, keyof L>>
  // Properties in R, with types that include undefined, that exist in L
  & SpreadProperties & keyof L>
  >;

(I've changed the linked definitions slightly; using Exclude from the standard library instead of Diff, and wrapping the Spread type with the no-op Id type to make the inspected type more tractable than a bunch of intersections).

Let's try it out:

function merge(a: A, b: B) {
  return Object.assign({}, a, b) as Spread;
}

const merged = merge({ a: 42 }, { b: "foo", a: "bar" });
// {a: string; b: string;} as desired

You can see that a in the output is now correctly recognized as a string instead of string & number. Yay!

---

But note that this is still an approximation:

• Object.assign() only copies enumerable, own properties, and the type system doesn't give you any way to represent the enumerability and ownership of a property to filter on. Meaning that merge({},new Date()) will look like type Date to TypeScript, even though at runtime none of the Date methods will be copied over and the output is essentially {}. This is a hard limit for now.

• Additionally, the definition of Spread doesn't really distinguish between missing properties and a property that is present with an undefined value. So merge({ a: 42}, {a: undefined}) is erroneously typed as {a: number} when it should be {a: undefined}. This can probably be fixed by redefining Spread, but I'm not 100% sure. And it might not be necessary for most users. (Edit: this can be fixed by redefining type OptionalPropertyNames = { [K in keyof T]-?: ({} extends { [P in K]: T[K] } ? K : never) }[keyof T])

• The type system can't do anything with properties it doesn't know about. declare const whoKnows: {}; const notGreat = merge({a: 42}, whoKnows); will have an output type of {a: number} at compile time, but if whoKnows happens to be {a: "bar"} (which is assignable to {}), then notGreat.a is a string at runtime but a number at compile time. Oops.

So be warned; the typing of Object.assign() as an intersection or a Spread<> is kind of a "best-effort" thing, and can lead you astray in edge cases.

---

Anyway, hope that helps. Good luck!

---

*Note: Someone edited the definition of Id from a identity mapped type to be just T. Such a change isn't incorrect, exactly, but it defeats the purpose... which is to iterate through the keys to eliminate intersections. Compare:

type Id = { [K in keyof T]: T[K] }

type Foo = { a: string } & { b: number };
type IdFoo = Id; // {a: string, b: number }

If you inspect IdFoo you will see that the intersection has been eliminated and the two constituents have been merged into a single type. Again, there's no real difference between Foo and IdFoo in terms of assignability; it's just that the latter is easier to read in some circumstances. Admittedly, sometimes the compiler's string representation of a type will just be the opaque-ish Id, so it's not perfect. But it did have a purpose. If you want to replace Id with T in your own code, be my guest.