0

It is known that each module in Node.js is wrapped in a function, where 5 arguments are passed in (i.e. exports, module, require, __filename, __dirname) and the module.exports object is returned.

Since exports is just an alias for module.exports, is there a reason why both module and exports are listed as 2 separate arguments? Wouldn't it be better if it was just module object being passed in? This would prevent the exports object from being unintentionally reassigned if the user were to do a top-level reassignment (e.g. exports = {x: 5}).

In terms of design, is it simply for the ease of accessing the exports object? I feel like I'm missing out something here.

I couldn't find this question being answered, but I'm happy to be redirected to an existing one.

// function (exports, module, require, __filename, __dirname) {

const a = 1;
console.log(a);

// return module.exports;
// }
Pottedtree
  • 7
  • 2
  • 2
  • 1
    [Googling “site:stackoverflow.com node.js exports vs module.exports”](//google.com/search?q=site%253Astackoverflow.com+node.js+exports+vs+module.exports) gets [module.exports vs exports in Node.js](/q/7137397/4642212). Also, this isn’t truly about “language design”, since Node.js is not a language and this particular behavior is only how this particular JS environment decided to handle things. – Sebastian Simon Dec 11 '21 at 07:03
  • Good read, I guess, but not specifically for this question. In that question there's this comment https://stackoverflow.com/questions/7137397/module-exports-vs-exports-in-node-js?noredirect=1&lq=1#comment50445513_26451885 which is quite close, but doesn't look... canonical. – user202729 Dec 11 '21 at 07:05
  • https://stackoverflow.com/questions/7137397/module-exports-vs-exports-in-node-js – HDM91 Dec 11 '21 at 07:05
  • Okay this answer https://stackoverflow.com/a/14424583/5267751 has a "more reasonable" explanation of the `exports` part. – user202729 Dec 11 '21 at 07:10
  • Thanks @user202729 :) Looks like the answer is stating that the reason is due to `module.exports` not being CommonJS-like - but I would assume the con of accidentally reassigning `exports` outweigh the advantage of being in alignment with the standard. – Pottedtree Dec 11 '21 at 07:39
  • If you think about it, it's not really breaking any standard, it's no different to `__dirname` been something extra in the node ecosystem, exports is just a reference to the existing standard, its not changed it. – Keith Dec 11 '21 at 09:18
  • @Keith No, in this case "the standard" is "use `exports`" (CommonJS standard), "breaking the standard" would be "use only `module.exports`". – user202729 Dec 11 '21 at 11:39
  • @user202729 Your probably right, but the point still stands if you switch it around. IOW: `module.exports`, doesn't break the commonjs spec, it's just something extra that node has exposed, like `__dirname` etc.. – Keith Dec 11 '21 at 13:57

1 Answers1

0

As node.js document said:

It allows a shortcut, so that module.exports.f = ... can be written more succinctly as exports.f = .... However, be aware that like any variable, if a new value is assigned to exports, it is no longer bound to module.export

module.exports.hello = true; // Exported from require of module
exports = { hello: false };  // Not exported, only available in the module

When the module.exports property is being completely replaced by a new object, it is common to also reassign exports:

module.exports = exports = function Constructor() {
  // ... etc.
};

https://nodejs.org/docs/latest/api/modules.html#exports-shortcut

HDM91
  • 1,318
  • 9
  • 16
  • 1
    Thanks @HDM91, I'm aware of what it does but I'm not sure why exporting has to be made available in 2 ways, apart from the fact that `exports` is more succinct. – Pottedtree Dec 11 '21 at 07:49