In a CommonJS module, what is the difference between `exports.parse = fn` and `module.exports = { parse: fn }`, and why does writing `exports = { parse: fn }` export nothing at all?

## Two names, one object — at first Before a CommonJS module's body runs, the host prepares a `module` object for the file and sets `module.exports` to a fresh empty object. It also introduces a module-local variable named `exports`, initialised to that same object. At the first line of your file, `exports === module.exports` is `true`. They are two references to one object, not two names for one storage slot. The distinction between *the object* and *the slot* is the whole question. `require` reads the slot: when the body finishes, it hands back the value stored in `module.exports`. It has no interest in your `exports` variable, which is invisible outside the module. ## The three forms **Attaching a property.** `exports.parse = fn` reaches through the reference and mutates the shared object. Because `module.exports` still points at that object, the property is visible to importers. `module.exports.parse = fn` is exactly equivalent while the two still agree. **Replacing the exports object.** `module.exports = { parse: fn }` writes a new object into the slot `require` reads, so importers get the new object. This is the form you need whenever the module's public value is not a plain namespace bag — a single function, a class, a constant. **Reassigning the alias.** `exports = { parse: fn }` is a bare assignment to a local variable. It changes what `exports` points at inside the file and nothing else. `module.exports` still holds the original empty object, so importers get `{}`: ```js // broken.js exports = { parse: () => 'nope' }; console.log(exports === module.exports); // false console.log(module.exports); // {} — this is what require returns ``` The failure is silent at the definition site: nothing throws, nothing warns, and the module looks correct on a skim. The symptom appears in the consumer as `TypeError: parse is not a function`, one file away from the cause. ## Why the mistake is so easy to make The two working forms make `exports` look like a first-class export mechanism, so it is natural to assume assigning to it is just the bulk version of attaching to it. It is not, and the reason is ordinary JavaScript reference semantics rather than anything module-specific: assigning to a variable that holds an object reference rebinds the variable; it never reaches through to whatever else references the object. Anybody who has been bitten by ```js function reset(obj) { obj = {}; } // caller's object is untouched ``` has already met the same rule in a different costume. ## Mixing the two styles Order matters when a file uses both forms: ```js exports.a = 1; // attaches to the original object module.exports = { b: 2 }; // replaces the slot; `a` is now unreachable // importers receive { b: 2 } ``` And after replacing `module.exports`, further use of `exports` is dead code, because `exports` still references the object that is no longer in the slot: ```js module.exports = class Repo {}; exports.helper = () => {}; // attaches to the abandoned object — invisible ``` This is a real review finding, not a puzzle: it typically shows up when a file grows a class export at the top and someone later adds a helper with the `exports.` habit further down. ## Practical guidance Pick one style per file. If the module exports a bag of named things, use `exports.x = ...` consistently and never assign to `exports`. If the module's value *is* one thing, assign `module.exports = ...` once, and from then on attach anything extra to `module.exports`, not to `exports`. Some teams sidestep the whole trap by never using the `exports` variable and always writing `module.exports.x = ...`, which costs a few characters and removes an entire class of silent bug. If you want a guard while debugging, `console.log(exports === module.exports)` at the end of a module tells you immediately whether the alias has been detached. ## How to answer it in an interview State the invariant first — `require` returns `module.exports`, full stop — then explain that `exports` is a convenience reference to the object that slot initially holds. Every case follows from those two sentences: mutation through either reference is visible, assignment to the slot is visible, assignment to the variable is not.