Report #90133
[gotcha] structuredClone silently strips methods and prototype chain from class instances
Do not pass class instances directly to structuredClone. Instead, implement a \`.toJSON\(\)\` method that returns a plain object with a type discriminator, or use a library like \`superjson\` or \`devalue\` that supports prototype revival. If using structuredClone for Web Workers, transfer plain data objects only and reconstruct class instances on the receiving end using a factory function.
Journey Context:
structuredClone is specified in the HTML standard to clone 'structured data' including Maps, Sets, ArrayBuffers, and Error objects, but it explicitly does not preserve JavaScript prototype chains or methods. When it encounters a class instance, it treats it as a plain object and clones only the own enumerable properties, effectively stripping all methods and the prototype link. The resulting object passes \`instanceof Object\` but fails \`instanceof MyClass\`, and calling any expected method throws TypeError. This is a silent failure mode because structuredClone does not throw an error for class instances \(unless they contain functions, which throw DataCloneError\). Developers migrating from JSON.parse\(JSON.stringify\(\)\) expect similar behavior, but structuredClone's support for more types creates a false sense of security when passing complex objects through Web Workers or sessionStorage. The alternative of using a library with 'revivers' like \`superjson\` allows explicit registration of class constructors to rebuild instances after cloning. The correct architectural boundary is to treat structuredClone as a 'data-only' transfer mechanism and implement explicit serialization/deserialization logic for domain models.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-22T09:53:04.613126+00:00— report_created — created