Develop Reference

require function inside or outside of prototype?

I often use prototypes such as these:
requiring the same or similar functions over and over in different files.
Would it be better to require Element inside the scope or outside the scope as done so below?
I guess it's should be outside, otherwise I will be creating lots of copies of Element all over my code, No?
var Element = require("./Element.js")
var _ = function(){
this.element = new Element();
this.stuff;
}
_.prototype.setStuff = function(stuff){
this.stuff = stuff
}
_.prototype.doStuff = function(){
this.stuff();
}
module.exports = _;
Thanks.

Since this is a node.js module, there are several considerations here:
require() is synchronous. Thus you don't ever want to use it inside of live server requests because that blocks the scalability of your server. You will generally want to use require() once when a module is initialized and your server is being initialized.
Variables declared within a node.js module are scoped only to the module. Technically the module scope is inside a module function so any variables declared there are already local variables and thus don't need any extra scope protection.
Modules are cached. So, it is very fast if you do require() multiple times on the same path. After the first time when the module is actually loaded and initialized, all subsequent calls just return the same cached module handle. So, don't try to mess with the structure of your code to reduce the number of places you call require(). Write clean code and if that necessitates calling require() a few times on the same module, that's no big deal.
requiring the same or similar functions over and over in different
files. Would it be better to require Element inside the scope or
outside the scope as done so below?
You usually want to put require() statements at the highest level in your node.js modules because you want to initialize them once when the module is first initialized and you want to share that module handle with all the code in the module. If your code is complex enough that you feel like calling require() for the same module in several different places to keep your code more partitioned, then you probably should be breaking your code into separate modules anyway and let each module require() in whatever it needs itself.
I guess it's should be outside, otherwise I will be creating lots of
copies of Element all over my code,
Outside at the highest scope in your module. There's really little reason not to just load the module once and share the module handle with all the code in the module that might want to use it.
There are a few special cases where you might want to dynamically load modules only in some specific conditions at run-time only when a module is needed. This is rare and has performance consequences when doing so because of the synchronous nature of loading modules so it is rarely done. So, I didn't want to be absolute in my earlier recommendation, but also wanted to explain that loading something only on-demand is rare and has consequences.

Here Element should be defined inside the _ function scope unless it is defined inside a IIFE.
If it is defined inside IIFE then there won't be any issue else Element will be exposed into window scope and using console we can override the Element function.
Hope this helps you.

Is there any reason to define module.exports using an IIFE?

My team doesn't have any experienced JS developers, but we are writing a library in Node and got a suggestion from a real JS developer that "We should make the js more modular - not to pollute the global namespace and to make it more readable to new-comers", and told us to do the following:
module.exports = (function(){
return {
nameToExpose: functionToExpose
...
};
})();
rather than
module.exports.nameToExpose = functionToExpose;
What's the point of this, if any? The latter does not make any local declarations that would be scoped by the IIFE, and even if it did, they would be local to the module file and not global to the whole program that require()s it.
Some Googling and poking about this site does not turn up any answers on this particular question, though there are many other explanations of IIFEs that I have read (and which are summarized in the above comment). Some testing certainly reveals that the latter does not actually put functionToExpose in the global namespace, though its original name is recorded in the function type itself.

Pretty much no difference. The whole idea of Node.js, using require, having modules, etc., is specifically to separate concerns. I'd say (cautiously) that if you're doing it right, you shouldn't be needing to worry about "polluting" any sort of global scope. Anything within module.exports lives in that module.
When you're dealing with front-end stuff, that's when the global scope becomes something of a concern, because if a function or whatever isn't scoped (i.e., in an IIFE, or other function block), it has access to the global window object, and everything else has access to that function.
a real JS developer
Calling someone that is a red flag.
not to pollute the global namespace and to make it more readable to new-comers
If you're modularizing your code correctly, that shouldn't be a concern. There's a time and a place for IIFEs, but I see no reason why wrapping everything in an IIFE, which is already inside of a module, would somehow magically make the code "more modular" or any more readable to "new comers" than by simply using Node.js like it was designed:
module.exports = function() { ... } // whatever
and even if it did, they would be local to the module file and not global to the whole program that require()s it.
You are correct. I'd take whatever he's saying with a grain of salt. Maybe he knows of some specific use-cases where his approach has been helpful to him in the past, so I'd ask him specifically about that to see what he says. Other than that, I feel like you're on the right track.

The reason to maybe sometimes do this is because if you don't, then any variables you need for the module.exports object have to be scoped to the entire file.
Consider these two ways.
Without IIFE.
var foo = 'la' + 'la'; // some computed value
//
// ... lots of program code here ...
//
module.exports = {
foo : foo,
};
With IIFE.
//
// ... lots of program code here ...
//
module.exports = (function () {
var foo = 'la' + 'la'; // some computed value
return {
foo : foo
}
}());
In the first example, two problems arise.
Your variables (like foo) are created quite far away from where they are used to export a value from the module. This can reduce clarity. Sure, you can declare a variable after the program code, but it still has the same scope (and vars are hoisted). Plus, general best practice is to declare all your variables up front, and not doing so is a tradeoff to consider.
The program code can mess around with your variables, intentionally or accidentally, which complicates things and is undesirable unless you need that (sometimes you do).
The second example eliminates these problems by having a private scope for that area of the file. You can still use variables that are scoped to the entire file, but in cases where you don't need that, you can have variables that are easier to read and understand.
Often times we program for humans, not machines. This is an example of optimizing for the former.
Update:
In modern versions of JavaScript, const and let are probably better solutions to the problems this pattern aims to solve. With them, you can define variables in a way that will throw errors if you make the same mistakes the IIFE is trying to protect you from.
//
// ... lots of program code here ...
//
const foo = 'la' + 'la'; // some computed value
module.exports = {
foo : foo,
};
In the above example, if the program code uses foo, it will crash with a ReferenceError, because of the Temporal Dead Zone, as opposed to receiving undefined as a var would. This is great because now you must explicitly move the declaration of foo to an earlier place in the code if its use was intentional, or otherwise fix the code.

It's a good idea. There's a lot about javascript that seems to push the envelope of how 'modern programming' is done. Maybe one of those is the modular system of CommonJS. But the evolution in javascript has always been along the lines of the classical object oriented paradigms of software development. It most likely always will be.
Javascript may do things differently, but it doesn't do different things... if that makes sense.
It's always a good idea to protect scope and objects from excessive mutations.
https://medium.com/backticks-tildes/the-s-o-l-i-d-principles-in-pictures-b34ce2f1e898

Nodejs global variables and modules

Are there any security issuses or something with using global variables and assignig modules to global variables in nodejs?
example:
client = new Client();
Without the var statement, so i can use it everywhere?

It's not that it's a security problem, it's considered bad practice though and it can lead to other problems such as trying to override a Node.js global variable.
Try not to pollute the global namespace and if you really really need global variables, just use one with sub-objects.

I don't think there are security issues per se, but you will be polluting the global namespace. As your project grows (especially with more than one programmer) the risk of conflicts gets bigger. And what if you later on add a third party library to your project that has a variable named 'client'?

I've been using Node for a couple of years and I had the same "problem" you have and is frustrating. Nevertheless I can give you the solution I reached and it works for me.
Node doesn't allows global variables in the way you ask since variables defined as global in a module are global only for that module. But exists a GLOBAL object that ban be used for what you need.
Global variables are a bad idea in general (always), but having a global cache of useful functions in it's own namespace is not a crime at all since it will not override anything and lets you use it along your code. So I'll tell you what I do to share functions and objects between modules and keep source organized (that's important for me at least!):
1st Create a resource file where you place all important functions and objects you want to share across your code. I call mine "R.js", R from Resources
2st Define the "R" object that will store all functions and objects and assign it to node's GLOBAL object:
var R = {};
GLOBAL.R = R; // Adds resource module to global
3rd For sake of simplicity and avoid extra requires all arround the code, I do all needed requires inside R.js. After that you only need to use them with R.require_variable.function_or_property
// All needed requires
R.fs = require('fs');
R.net = require('net');
R.http = require('http');
R.dbClient = require('mysql').Client;
...
4th Create the shared functions, variables and objects you like inside the R object
5th Where needed arround your code, require the R.js file and access to it's member by using the R object
R.<property_or_function>
2 warning notes.
Remember to always call shared functions or user shared objects placind "R." in front of it
Althought you can assign new functions, objects and properties to R object anywhere this can lead to the same inconsistencies you would have with global variables if you don't plan it in advance - i.e. you call a shared function before assigning it to R - so as a methodology, create everything in the R.js file instead of doing it all arround your code. This way all shared things will be in R.js and that is the only place to look for shared code.

Does Node.js require inheritance?

In my server.js file I included the Underscore.js library.
var _ = require('underscore')
I have my routes like this:
// require routes
require('./routes/document');
In the document route, I want to use Underscore.js. But it seems like the _ variable is not inherited/inside the document scope. Does that mean I have to set the _ variable on every single required route? Or is there a more intelligent way to do this?

Yes, you should set the _ in the files that needs it to be available.
Alternatively, you can put it in the global scope by removing the var part.
_ = require('underscore');
require('./routes/document'); // _ will be visible in document as well

Check the Node.js module documentation where require() is thoroughly explained.
http://nodejs.org/docs/v0.4.5/api/modules.html
As for your specifics:
Modules are cached after the first time they are loaded. This means (among other things) that every call to require('foo') will get exactly the same object returned, if it would resolve to the same file.
Hence, if you require('underscore') in both your parent library and './routes/document', only one instance of the underscore module will be loaded and hence. Both variables will be in fact the same object.
And by the way, you don't want to define variables in the global scope as it might generates side effects and potentially overwrite properties in other modules.
Finally, the util module provides an inherits method to subclass another constructor and inherit from its prototypes.
http://nodejs.org/docs/v0.4.5/api/util.html#util.inherits

As far as I know Node.js engine "requires/charges" a module/file.js in a different scope (I don't know exactly how), for security reasons (imagine a module could change the variables were it's required. That would be dangerous! More information about this concern: Information hiding).
The only exception are global Node.js objects that are exposed into the module scope.
A global object is, precisely the object "global", and everything you define without var keyword actually is added to that global object:
foo_var = "Whatever"
means that:
console.log(global.foo_var) // Logs "Whatever"

Global variables for node.js standard modules?

I know that global variables are bad.
But if I am using node's module "util" in 40 files in my framework, isn't it better to just declare it as a global variable like:
util = require('util');
in the index.js file instead of writing that line in 40 files?
Cause I often use the same 5-10 modules in each file, that would save a lot of time instead of copy paste all the time.
Isn't DRY good in this case?

You could just have a common module.
common.js:
Common = {
util: require('util'),
fs: require('fs'),
path: require('path')
};
module.exports = Common;
app.js:
var Common = require('./common.js');
console.log(Common.util.inspect(Common));

Each module is supposed to be independent. The require doesn't cost anything anyways after the first one for each module.
What if you wanted to test one module alone? You'd be having a lot of issues because it wouldn't recognize some "global" requires that you have in your app.
Yes, globals are bad, even in this case. Globals almost always ruin: testability, encapsulation and ease of maintenance.
Updated answer Jan. 2012
The global object is now a global inside each module. So every time you assign to a global variable (no scope) inside a module, that becomes part of the global object of that module.
The global object is therefore still not global, and cannot be used as such.
Updated Dec. 2012
The global object now has the global scope within the application and can be used to store any data/functions that need to be accessed from all modules.

global.util = require('util');
There's a section about global objects in the node documentation.
However, globals should be used with care. By adding modules to the global space you reduce testability and encapsulation. But there are cases where using this method is acceptable. For example, I add functions and objects to the global namespace to use within my unit test scripts.

I'm confused by the answers in this thread.
I am able to do this...
File: test.js
global.mytest = {
x: 3,
y: function() { console.log('Works.'); }
};
File: test2.js
console.log('Does this work?');
mytest.y();
File: server.js
require('test.js');
require('test2.js');
And it seems to work as the question needed. The first require places the mytest object into the global scope, then the second require can access that object without any other qualifiers.
I was trying to figure this out (which brought me to this thread from a Google search) and I wanted to post what seems to work for me now. Maybe things have changed since the original answers.

I have successfully been using the process object for passing around my configuration object. While in theory suffering from the exact same issues as mentioned above (encapsulation, testability and so forth) it works fine when using only non-state modifying properties (a hash table with primitives, basically).

If you wrap your modules in blocks (e.g. anon functions) you can bind to a local name (via parameter or 'var') and then have any arbitrary long (perhaps "package" labeled) name you want (if you even need a global at this point).
For instance, my modules often look similar to:
;(function ($, $exp, other) {
$(...)
other.xyz()
$exp.MyExportedObject = ...;
})(jQuery, window, some_module.other_expression) // end module
I use jQuery with noConflict, this the former, and the latter show you can do this for any expression -- global, require, computed, in-line, whatever... this same "wrapping" approach can be used to eliminate all (or almost all) "special named" globals -- globals must exist at some level, however, removing potentially conflicts is a very big win.