What is the best way to pass common variables into separate modules in Node.js?

I use separate router files as modules for main app and auth app. I can't get the best way to pass variables(db client) into routers. I don't want to hardcode it or pass it with:

module.exports = function(app, db) {

Maybe it's best way to use singleton register or use global db variable?

What is your experiense with design-patterns? Which way is the best and why?

I have found using dependency injection, to pass things in, to be the best style. It would indeed look something like you have:

// App.js
module.exports = function App() {
};

// Database.js
module.exports = function Database(configuration) {
};

// Routes.js
module.exports = function Routes(app, database) {
};

// server.js: composition root
var App = require("./App");
var Database = require("./Database");
var Routes = require("./Routes");
var dbConfig = require("./dbconfig.json");

var app = new App();
var database = new Database(dbConfig);
var routes = new Routes(app, database);

// Use routes.

This has a number of benefits:

• It forces you to separate your system into components with clear dependencies, instead of hiding the dependencies somewhere in the middle of the file where they call require("databaseSingleton") or worse, global.database.
• It makes unit testing very easy: if I want to test Routes in isolation, I can inject it with fake app and database params and test only the Routes code itself.
• It puts all your object-graph wiring together in a single place, namely the composition root (which in this case is server.js, the app entry point). This gives you a single place to look to see how everything fits together in the system.

One of the better explanations for this that I've seen is http://www.infoq.com/articles/DI-Mark-Seemann">an interview with Mark Seeman, author of the excellent book Dependency Injection in .NET. It applies just as much to JavaScript, and especially to Node.js: require is often used as a classic service locator, instead of just a module system.

I suggest you create a settings file with db instance and with other things which you need use globally like 'singleton'.

For example, I have settings.js with my redis db client:

var redis = require('redis');
exports.redis = redis.createClient(6379, '127.0.0.1');

And in other multiple modules I include it:

var settings = require('./settings');
setting.redis.<...>

Many time including it I always have one instance of db connection.

You can save yourself all the boilerplate code of wiring up your modules if you use a dependency injection framework

This answer lists a few of them. I also built a simpler DI framework here.

EDIT: below is a copy form the answer in case that page changes

---

require is the way of managing dependencies in Node.js and surely it is intuitive and effective, but it has also its limitations.

My advice is to take a look at some of the Dependency Injection containers available today for Node.js to have an idea on what are their pros/cons. Some of them are:

• Scatter
• Electrolyte
• Wire
• Intravenous
• Pongular

Just to name a few.

Now the real question is, what can you achieve with a Node.js DI container, compared to a simple require?

Pros:

• better testability: modules accepts their dependencies as input
• Inversion of Control: decide how to wire your modules without touching the main code of your application.
• a customizable algorithm for resolving modules: dependencies have "virtual" identifiers, usually they are not bound to a path on the filesystem.
• Better extensibility: enabled by IoC and "virtual" identifiers.
• Other fancy stuff possible:
• Async initialization
• Module lifecycle management
• Extensibility of the DI container itself
• Can easily implement higher level abstractions (e.g. AOP)

Cons:

• Different from the Node.js "experience": not using require definitely feels like you are deviating from the Node way of thinking.
• The relationship between a dependency and its implementation is not always explicit. A dependency may be resolved at runtime and influenced by various parameters. The code becomes more difficult to understand and debug
• Slower startup time
• Maturity (at the moment): none of the current solutions is really popular at the moment, so not so many tutorials, no ecosystem, not battle tested.
• Some DI containers will not play well with module bundlers like Browserify and Webpack.

It is completely outdated, but you can use global in a script :

 global.foo = new Foo();

in another script :

 foo.bar();

You can also use already existing constant :

 Object.foo = new Foo();

And here :

 Object.foo.bar();