Singleton pattern in nodejs - is it needed?

Question

All of the above is overcomplicated. There is a school of thought which says design patterns are showing deficiencies of actual language.

Languages with prototype-based OOP (classless) do not need a singleton pattern at all. You simply create a single(ton) object on the fly and then use it.

As for modules in node, yes, by default they are cached, but it can be tweaked for example if you want hot-loading of module changes.

But yes, if you want to use shared object all over, putting it in a module exports is fine. Just do not complicate it with "singleton pattern", no need for it in JavaScript.

This has basically to do with nodejs caching. Plain and simple.

https://nodejs.org/api/modules.html#modules_caching

(v 6.3.1)

Caching

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.

Multiple calls to require('foo') may not cause the module code to be executed multiple times. This is an important feature. With it, "partially done" objects can be returned, thus allowing transitive dependencies to be loaded even when they would cause cycles.

If you want to have a module execute code multiple times, then export a function, and call that function.

Module Caching Caveats

Modules are cached based on their resolved filename. Since modules may resolve to a different filename based on the location of the calling module (loading from node_modules folders), it is not a guarantee that require('foo') will always return the exact same object, if it would resolve to different files.

Additionally, on case-insensitive file systems or operating systems, different resolved filenames can point to the same file, but the cache will still treat them as different modules and will reload the file multiple times. For example, require('./foo') and require('./FOO') return two different objects, irrespective of whether or not ./foo and ./FOO are the same file.

So in simple terms.

If you want a Singleton; export an object.

If you do not want a Singleton; export a function (and do stuff/return stuff/whatever in that function).

To be VERY clear, if you do this properly it should work, look at https://stackoverflow.com/a/33746703/1137669 (Allen Luce's answer). It explains in code what happens when caching fails due to differently resolved filenames. But if you ALWAYS resolve to the same filename it should work.

Update 2016

creating a true singleton in node.js with es6 symbols Another solution: in this link

Update 2020

This answer refers to CommonJS (Node.js's own way to import/export modules). Node.js will most likely be switching over to ECMAScript Modules: https://nodejs.org/api/esm.html (ECMAScript is the real name of JavaScript if you didn't know)

When migrating to ECMAScript read the following for now: https://nodejs.org/api/esm.html#esm_writing_dual_packages_while_avoiding_or_minimizing_hazards

No. When Node's module caching fails, that singleton pattern fails. I modified the example to run meaningfully on OSX:

var sg = require("./singleton.js");
var sg2 = require("./singleton.js");
sg.add(1, "test");
sg2.add(2, "test2");

console.log(sg.getSocketList(), sg2.getSocketList());

This gives the output the author anticipated:

{ '1': 'test', '2': 'test2' } { '1': 'test', '2': 'test2' }

But a small modification defeats caching. On OSX, do this:

var sg = require("./singleton.js");
var sg2 = require("./SINGLETON.js");
sg.add(1, "test");
sg2.add(2, "test2");

console.log(sg.getSocketList(), sg2.getSocketList());

Or, on Linux:

% ln singleton.js singleton2.js

Then change the sg2 require line to:

var sg2 = require("./singleton2.js");

And bam, the singleton is defeated:

{ '1': 'test' } { '2': 'test2' }

I don't know of an acceptable way to get around this. If you really feel the need to make something singleton-like and are okay with polluting the global namespace (and the many problems that can result), you can change the author's getInstance() and exports lines to:

singleton.getInstance = function(){
  if(global.singleton_instance === undefined)
    global.singleton_instance = new singleton();
  return global.singleton_instance;
}

module.exports = singleton.getInstance();

That said, I've never run into a situation on a production system where I needed to do anything like this. I've also never felt the need to use the singleton pattern in Javascript.

Looking a little further at the Module Caching Caveats in the Modules docs:

Modules are cached based on their resolved filename. Since modules may resolve to a different filename based on the location of the calling module (loading from node_modules folders), it is not a guarantee that require('foo') will always return the exact same object, if it would resolve to different files.

So, depending on where you are when you're requiring a module, it's possible to get a different instance of the module.

Sounds like modules are not a simple solution to creating singletons.

Edit: Or maybe they are. Like @mkoryak, I can't come up with a case where a single file might resolve to different filenames (without using symlinks). But (as @JohnnyHK comments), multiple copies of a file in different node_modules directories will each be loaded and stored separately.