In node.js we can use
module.exports
exports
exports is shorthand for module.exports.
In my opinion, providing module.exports and exports is confusing.
It is not only confusing but error prone also because we can reassign one.
Why module.exports is not the only way to export?
What was the goal to provide both?
The documentation says it's so that code writing to export can be more concise:
exports shortcut
The exports variable is available within a module's file-level scope, and is assigned the value of module.exports before the module is evaluated.
It allows a shortcut, so that module.exports.f = ... can be written more succinctly as exports.f = ....
(my emphasis)
Related
In some place i see people using "module.exports" and in others "exports",what is the difference ?
exports is assigned to module.exports by default. So, they are essentially the same. Unless you reassign exports.
https://nodejs.org/api/modules.html#modules_exports_alias
In the guide of the Brunch website, they start the config file as following module.exports = config:, however most of the skeletons you can find on the same website use another syntax exports.config =.
What is the difference between them? Are both javascript CommonJS Module?
I had a look directly at the doc: module node documentation. Something I should have done at first :)
The exports variable that is available within a module starts as a reference to module.exports. As with any variable, if you assign a new value to it, it is no longer bound to the previous value.
If you want the root of your module's export to be a function (such as a constructor) or if you want to export a complete object in one assignment instead of building it one property at a time, assign it to module.exports instead of exports.
Finally, they said:
As a guideline, if the relationship between exports and module.exports seems like magic to you, ignore exports and only use module.exports.
Et voilà!
In the server.js file of mean.io
I can see
//expose app
exports = module.exports = app;
Can anyone explain me the meaning, what is it for ?
File in Question: https://github.com/linnovate/mean/blob/master/server.js
I would write something up, but I found an article that covers it nicely:
[ . . . ] In /src/node.js you can see that your
code is wrapped in a closure and passed both exports and module. Of
course, further inspection will show you that exports contains a
pointer to module.exports and suddenly everything makes sense.
Overwriting exports overwrites the pointer to module.exports which
disconnects exports from the Node.js environment!
What’s the point?
Exports is a helper function that points to module.exports. This is
meant to make your life easier. That is all. Use it to expose
functions of your module, but if your module needs to replace what is
exposed, you must use module.exports.
Open up that article and take a look at the examples that are provided for more information.
In short, it's a way of making the app variable be referenced directly when it's required from another module instead of being nestled into an object, e.g.
// hello.js
module.exports = 'hello';
// foo.js
exports.foo = 'bar';
// testing it out
console.log(require('hello.js')); // outputs 'hello'
console.log(require('foo.js')); // outputs { foo: 'bar' }
I'm refactoring a large javascript codebase to use RequireJS. Unfortunately, many of the files I'm dealing with are not object-oriented, and cannot return an object without significant modification. Is there a more efficient way to give 'dependent' modules access to the functions and variables contained in a module (without returning an object) ?
I have read about using the exports syntax for defining modules, but it is very unclear whether that would be a valid solution for this situation.
In a defined module, the exports object is what gets exported from the module and passed to whatever module requires it.
Consider this:
define(["exports"], function(exports){
exports.myCustomFunction = function(){};
exports.myCustomObject = {};
exports.myCustomVariable = true;
})
This module will place all the disparate functions and/or objects that you want made public onto the exports object.
At this point RequireJS will use that exports object to pass to a module that requires it:
require(["nameOfCustomModule|filename"], function(myCustomModule){
//evaluates to true
console.log(myCustomModule.myCustomVariable);
})
Here's a simple fiddle. Just bring up your console and you will see the value logged there. http://jsfiddle.net/xeucv/
Hope this clears it up a bit!
Trying to understand what would be the best way to structure some variables. For example in my Node.js Express app, I have the following in app.js:
var poolModule = require('generic-pool');
global.pools = {
/* ... */
};
Where pools is my global variable that keeps track of MySQL and Redis pools. I am also wondering if I can do the same with actual Redis and MySQL objects (and maybe configs variable) so I don't have to require them all over the app. And since they are going to be used the most.
Is this bad practice, and if yes, what's a better way to structure this kind of code?
Edit: added global.
If you require a file you are actually always requiring the same object. So that means you can do:
module.exports = {
// same object for everybody that requires me
};
You have the right idea, but you want to use module.exports to export your object as a module. The CommonJS approach is to have local variables within the module and exported variables for use outside the module. In this way modules can access each others' variables through the use of require. These variables aren't really "global", but in a way are more like "friend" classes in C++. You can in fact have your poolModule do more than store variables for you--you could put methods and other functionality in there too and make it reusable across your whole application.