A config object built as `{...defaults, ...userOptions}` loses nested defaults and, when the source was a class instance, its methods too. What does object spread actually copy, and why do both symptoms follow?

## The rule spread follows Object spread copies each source's **own enumerable** properties onto a fresh object literal, in source order, defining each key as a plain data property. Everything surprising about it falls out of that one sentence. ### Later wins, per key, at the top level only ```js const defaults = { retry: { count: 3, delay: 100 }, verbose: false }; const userOptions = { retry: { count: 5 } }; const config = { ...defaults, ...userOptions }; config.retry; // { count: 5 } — delay is gone config.verbose; // false — untouched key survives ``` Merging happens between keys, never inside them. `retry` existed in both sources, so the second value replaced the first outright. A key that appears in only one source passes through, which is why the pattern looks correct on flat objects and quietly loses data the moment options grow a nested level. If you need a nested merge you write it yourself, level by level: ```js const merged = { ...defaults, ...userOptions, retry: { ...defaults.retry, ...userOptions.retry }, }; ``` Once that list of hand-merged keys grows past two or three, a generic deep-merge helper or a flattened options shape is the honest answer. ### `undefined` is a value, not an absence ```js const opts = { timeout: undefined }; const c = { timeout: 30, ...opts }; c.timeout; // undefined — the default was overwritten ``` This bites whenever options are assembled programmatically and an unset field is materialized as `undefined` rather than omitted. Guard by stripping undefined values before spreading, or by applying `??` per field after the merge. ### Own means own: the prototype stays behind ```js class Client { constructor(url) { this.url = url; } send() { /* ... */ } } const c = new Client('/api'); const copy = { ...c }; copy.url; // '/api' — instance field copied copy.send; // undefined — method lives on Client.prototype copy instanceof Client; // false — copy is a plain object ``` Class methods are properties of the prototype, not of the instance, so they are not own properties and spread never sees them. The result is a plain object that carries the data and none of the behaviour — which is fine when you *wanted* a data snapshot, and a real defect when the value is passed on to something that expects to call methods on it. Class fields declared as instance fields (including arrow-function fields) *are* own properties and do come along, which makes the outcome look inconsistent unless you know the rule. Non-enumerable own properties are skipped for the same reason: `Object.defineProperty(obj, 'secret', { value: 1, enumerable: false })` survives no spread. Own enumerable **symbol** keys, by contrast, are copied — spread is not a string-key-only operation. ### Getters are invoked, not carried ```js let reads = 0; const source = { get now() { reads++; return Date.now(); } }; const snap = { ...source }; // reads === 1; snap.now is a fixed number, not an accessor ``` Spread reads each property's value and defines a data property with it. An accessor therefore runs once at copy time and becomes a frozen result. That is desirable for snapshots and wrong for lazily computed or live fields — and it means spreading an object can have side effects if its getters do. ## Spread versus `Object.assign` They are close but not identical. `Object.assign(target, source)` mutates an existing target and *assigns* each key, which triggers any setter already defined on the target and respects a non-writable property by throwing in strict mode. Object spread always creates a fresh object and *defines* each key, so no setter on any prototype interferes. When you are building a new object, spread is the safer of the two; `Object.assign` is for deliberately mutating something that already exists. ## How to answer Give the one-line rule first — own enumerable properties, one level, later sources win — and then derive each symptom from it: nested keys replaced because merging is per key; methods missing because they are inherited, not own; stale snapshots because getters are read eagerly; defaults clobbered because `undefined` is a value. Closing with the explicit per-level merge, and the observation that it stops scaling, is what makes this read as production experience rather than syntax recall.