Override helper-type

[mindplay-dk]

Suggestion

🔍 Search Terms

override type

✅ 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
• [ x 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

Add an Override helper-type to your library of utility types.

📃 Motivating Example

My use-case is a domain model with a matching JSON payload, but the JSON payload has some differences.

Upon loading the "packed" JSON payload, I will unpack it to the proper domain model - here, I am reusing the proper model type, replacing the properties that are "packed" into tuples.

The & union type operator doesn't work for this, because it performs declaration merging by default, and (from what I could find) there is no way to opt-out of that.

Example:

interface Model {
  foo: string;
  bar: string[];
  baz: number;
  items: Item[]
}

interface Item {
  a: string;
  b: string;
  c: string;
}

type ItemJSON = [string, string, string]; // JSON payload is "packed" to save bandwidth

type ModelJSON = Override<Model, {
  items: ItemJSON[];
}>;

function unpack(json: ModelJSON): Model {
  return {
    ...json,
    items: json.items.map(array => ({
      a: array[0],
      b: array[1],
      c: array[2],
    })),
  }
}

The proposed Override type: (reuses the Pick and Exclude helpers to reduce verbosity)

/**
 * Override and replace the properties of T with with those in type U.
 */
type Override<T, U> = Pick<T, Exclude<keyof T, keyof U>> & U;

💻 Use Cases

The example above is the use-case.

For now, I am manually adding this type to my projects - but it seems like a common enough requirement that this might be worth considering as a standard utility type?

(I have a branch here, which includes a simple test - I would have just submitted a PR, but your PR policy says not to do that without first getting it on the roadmap, so... let's see what you think? 🙂)

[MartinJohns]

See #39522 (comment):

We've opted to not include utility type aliases in the lib unless they're required for declaration emit purposes.