Global variables for node.js standard modules?

Question

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

Answer 1

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));

Answer 2

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).

Answer 3

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.

Answer 4

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.

Answer 5

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.

Answer 6

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.