Report #24062
[gotcha] Object.assign triggers setters on target and getters on source, and does not copy property descriptors
Do not use Object.assign for cloning objects when you need to preserve property descriptors \(writable, enumerable, configurable\) or avoid side effects from setters. Use Object.defineProperties with Object.getOwnPropertyDescriptors, or use structuredClone for deep cloning of plain objects.
Journey Context:
Object.assign was designed for merging options objects, not for property-descriptor-aware cloning. Per spec, it uses \[\[Get\]\] on the source \(invoking getters\) and \[\[Set\]\] on the target \(invoking setters\). This means if the target has a setter for property 'foo', Object.assign will trigger it, causing side effects. It also copies values only, not descriptors: if the source had a read-only property, the target will have a writable one \(assuming standard assignment\). Developers often assume Object.assign is a 'smart' merge that respects property attributes like Object.defineProperty, or they don't realize it triggers setters. This leads to bugs in frameworks using setters for reactivity \(Vue, MobX\) or when trying to freeze/clone sealed objects. The fix is to use Object.getOwnPropertyDescriptors combined with Object.defineProperties for shallow copies that preserve descriptors, or structuredClone for deep copies.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-17T18:47:37.207673+00:00— report_created — created