A JavaScript constructor function stores its first instance on a property of itself and returns that stored object on every later call, so `new Config()` always yields the same object. How does that work, and what problems does it cause in production code?

## The mechanism The trick rests entirely on one rule: when a constructor's body returns an object, `new` hands back that object instead of the `this` it created. ```js function Config(options) { if (Config.instance) return Config.instance; this.options = options; Config.instance = this; } const a = new Config({ mode: 'a' }); const b = new Config({ mode: 'b' }); a === b; // true b.options.mode; // 'a' ``` The first call takes the normal path: a fresh object is created, populated, and stored on the constructor function (which is itself just an object and can carry properties). Every later call creates a fresh `this`, immediately abandons it via the `return`, and gives the caller the cached one. The abandoned objects are garbage - a small but real cost if the constructor is called in a loop. A variant caches per key rather than a single instance, giving interning: ```js function Currency(code) { const cached = Currency.cache.get(code); if (cached) return cached; this.code = code; Currency.cache.set(code, this); } Currency.cache = new Map(); new Currency('EUR') === new Currency('EUR'); // true ``` ## Why `instanceof` still passes for the base The cached object was genuinely produced by `new Config(...)`, so its `[[Prototype]]` is `Config.prototype` and `cached instanceof Config` is `true`. That is what makes the trick feel harmless: the type test the caller would run still succeeds. ## Where it breaks: subclassing This is the failure worth being able to name. ```js class Extended extends Config {} const e = new Extended({}); e === a; // true - the cached base instance e instanceof Extended; // false - its prototype is Config.prototype ``` A derived constructor's `this` is whatever the parent construction produced. Because the parent returned the cached object, that object becomes the derived `this` and is what `new Extended()` evaluates to. It was created before `Extended` existed, so it is linked to `Config.prototype`: none of `Extended`'s prototype methods are reachable, none of its class fields were installed, and the `instanceof` test that callers rely on returns `false`. The failure is silent until someone calls a subclass method. ## The other production costs - **Arguments are silently ignored.** `new Config({ mode: 'b' })` looks like it configured something. It configured nothing. There is no error, no warning - just the first caller's options, forever. Whichever module happens to import and construct first wins, which makes behaviour depend on import order. - **Hidden global state.** The cache lives for the lifetime of the process (or the page). Tests that need a clean instance must reach into the implementation and delete `Config.instance`, coupling the test suite to a private detail. Parallel tests sharing a process interfere with each other. - **Unbounded keyed caches leak.** The per-key variant keeps a strong reference to every instance ever created; if keys come from user input, the map grows without limit. - **It violates the contract of `new`.** Every reader of `new X()` assumes a fresh object. Code that mutates "its" instance, or compares two instances for identity, quietly operates on shared state. ## What to do instead Make the sharing visible at the call site rather than hiding it behind `new`: ```js let instance; export function getConfig(options) { instance ??= new Config(options); return instance; } ``` or, simpler still in a module system where a module body evaluates once, export a configured object directly. Both remove the lie: nobody writes `new` and receives something old. If a class must remain the public surface, a `static create()` or a static registry method is clearer than an invisible override inside the constructor. ## How this is asked Usually as "can you make `new Foo()` always return the same object?" followed by "what would go wrong?". Producing the code is the easy half; the discriminating half is naming the subclass breakage, the silently discarded arguments, and the testability problem, then proposing the explicit factory. Candidates who present the trick as a best-practice singleton pattern without any of those caveats read as inexperienced.