Answer.

In JavaScript, the Spread operator (...) was introduced for convenience in copying and extending objects, and it has long been used with arrays, and starting from ES2018 — also with objects. In TypeScript, Spread has become not just a syntactic improvement, but a tool for precise typing when manipulating objects.

Historically, in JavaScript, object cloning or extension was done through Object.assign, but this approach easily led to a loss of type safety and dangerous key collisions if the object structure is complex.

The problem is that when using Spread to combine/extend objects, TypeScript infers a new type based on the input structures, resolving potential key conflicts ("last one wins"), but this is not always what the developer intended. Particular attention should be paid to intersections with optional fields, readonly properties, and the presence of private properties in classes.

Solution: use Spread while allowing the TypeScript compiler to infer the result automatically. For complex cases, it is important to explicitly constrain the type of input structures and closely monitor changes in type structures.

Code example:

interface User {
  name: string;
  age: number;
}

interface Extra {
  isAdmin?: boolean;
  readonly city: string;
}

const base: User = { name: 'Ivan', age: 28 };
const extended: User & Extra = { ...base, city: 'Moscow', isAdmin: true };

Key features:

Spread merges keys, the last encountered key determines the value and type.
readonly and optional fields are carried over but can be overwritten if the original types conflict.
When extending classes, private properties are not copied, which can lead to errors.

Tricky questions.

Can you achieve a "deep copy" of an object in TypeScript using Spread inheritance?

Answer: No. Spread only performs a shallow copy; nested objects remain referenced.

const original = { user: { name: 'Anna' } };
const cloned = { ...original };
cloned.user.name = 'Maria'; // original.user.name also changes

Will the type be narrowed or expanded when spreading objects with overlapping keys, and how does this affect variable annotation?

Answer: During Spread, the variable type expands, and in case of key collisions, properties on the right prevail; if there's an explicit type annotation, it may lead to an error if types are incompatible.

const a = { id: 4, value: "abc" };
const b = { value: 123 };
const c: { id: number; value: number } = { ...a, ...b }; // ok

Can Spread be applied to classes and what happens with private properties?

Answer: Spread is applicable only to public properties of a class. Private (private/#) and protected protected fields do not get included in the resulting object.

class Person {
  private id = 77;
  name = "Bob";
}
const p = new Person();
const spreaded = { ...p }; // spreaded: { name: string }

Type errors and anti-patterns

Attempting to use Spread for deep copying nested objects.
Forgetting about the dangers of key collision and type changes.
Using Spread with class instances expecting to copy private properties.
Applying Spread to arrays with heterogeneous types, losing type safety.

Real-life example

Negative case

A developer performs Spread of the values of the settings object to extend user options:

const common = { theme: 'light', notifications: true };
const user = { notifications: false, signature: 'Sasha' };
const merged = { ...common, ...user };

Expecting merged to be type-consistent, but accidentally allows an error with the type of the signature field, forgetting that Spread simply copies keys and does not validate their values.

Pros:

Quick and convenient to merge objects

Cons:

Overriding significant values, losing some required properties, unnoticed errors when adding new keys.

Positive case

For merging configurations, Spread is used only after validation and with return type annotation:

interface Settings {
  theme: "light" | "dark";
  notifications: boolean;
  signature?: string;
}
function getSettings(common: Settings, specific: Partial<Settings>): Settings {
  return { ...common, ...specific };
}