A JavaScript module is built like this: `const mod = (function () { function a() { return 'original a'; } function b() { return a(); } return { a, b }; })();`. A caller then does `mod.a = () => 'patched a';`. Why does `mod.b()` still return 'original a', and what does that tell you about what the returned object holds?

## What the return statement actually does `return { a, b };` is shorthand for `return { a: a, b: b };`. Object literals evaluate their property values eagerly: at that instant the engine reads the current value of the binding `a`, which is the function object, and stores that reference in a new property. There is no ongoing link between the property `mod.a` and the variable `a`. They start out pointing at the same function object and can drift apart the moment either side is reassigned. ## Why `b` does not consult `mod` `b`'s body contains the identifier `a`. Identifier resolution has exactly one strategy: walk the scope chain outward from where the code was written until a binding with that name is found. `b` was written inside the wrapper, so the first `a` it finds is the wrapper's local one. The object `mod` plays no part in that lookup — `mod` is a value the wrapper never even names, since it is created by the caller's assignment after the call returns. The consequence is a two-world split: ```js mod.a(); // 'patched a' -- external callers see the patch mod.b(); // 'original a' -- internal calls do not ``` That inconsistency is what makes the bug expensive: the patch appears to work when you test it directly and silently fails in every code path that goes through another method. ## The mirror case The same decoupling bites from the inside out: ```js const mod2 = (function () { let a = () => 'v1'; const b = () => a(); function upgrade() { a = () => 'v2'; } // reassign the inner binding return { a, b, upgrade }; })(); mod2.upgrade(); mod2.b(); // 'v2' -- b closes over the live binding mod2.a(); // 'v1' -- the property still holds the old function value ``` So the returned object is a snapshot while the internal references are live. Whichever direction the reassignment happens in, the two views disagree. ## Contrast with the object-literal style Write the same module with the methods defined directly on the returned object and calling each other through `this`, and the patch takes effect everywhere: ```js const mod3 = (function () { return { a() { return 'original a'; }, b() { return this.a(); }, // dispatches through the object }; })(); mod3.a = () => 'patched a'; mod3.b(); // 'patched a' ``` That is a genuine tradeoff rather than a fix. Dispatching through `this` makes the method overridable — good if you want a seam, bad if the internal call was supposed to be an implementation detail that no caller can subvert. It also inherits every `this`-binding hazard: pull `mod3.b` out into a variable or pass it as a callback and the receiver is lost. ## Choosing deliberately Decide what you want the public surface to *be*. If it is a closed API — the module's behaviour is fixed and callers only consume it — the snapshot semantics are a feature. Nobody can monkey-patch a code path in a way that half-works, and the internals are free to be refactored because no caller can reach into them. If you genuinely need a seam — for tests, for a pluggable strategy, for an environment-specific implementation — do not rely on property patching. Take the collaborator as a parameter to the factory, or expose an explicit setter that reassigns the *inner* binding: ```js const mod4 = (function () { let formatter = (s) => s.trim(); return { setFormatter(fn) { formatter = fn; }, // rewires the internal binding render(s) { return formatter(s); }, }; })(); ``` Now the rewiring is part of the contract, is visible in the public surface, and applies to every internal call — no snapshot to drift out of sync. ## Diagnosing it in the wild The signature of this bug in a real codebase is a test that stubs a module method and passes, alongside production behaviour that never changed — or the reverse, a stub that appears to leak because some other method still runs the original and mutates shared state. When you see "I patched it and it only sometimes takes effect", check whether the caller is going through the property or through a closed-over binding. Grep the module for internal calls to its own exported names; each one is a call site the patch will not reach.