Take the 2-minute tour ×

I have several apps in node that all share a few modules that I've written. These modules are not available via npm. I would like to be able to share freely between apps, but I don't want to copy directories around, nor rely on Git to do so. And I'm not really big on using symlinks to do this either.

I would like to arrange directories something like this:

  (public modules from npm needed for app1)
  (my own modules specific to app1)

  (public modules from npm needed for app2)
  (my own modules specific to app2)

 (my own modules that are used in both app1 and app2)

The problem I'm seeing is that the modules in shared_lib seem to get confused as to where to find the modules that will be in the node_modules directory of whichever app they are running in. At least I think that is the problem.

So....what is a good way to do this that avoids having duplicates of files? (note that I don't care about duplicates of things in node_modules, since those aren't my code, I don't check them into Git, etc)

share|improve this question
add comment

4 Answers

up vote 2 down vote accepted

I've got this working by having node_modules folders at different levels - node then automatically traverses upwards until it finds the module.

Note you don't have to publish to npm to have a module inside of node_modules - just use:

"private": true

Inside each of your private package.json files - for your project I would have the following:

  (public modules from npm needed for app1)
  (private modules locally needed for app1)

  (public modules from npm needed for app2)
  (private modules locally needed for app2)

  (public modules from npm needed for app1 & app2)
  (private modules locally for app1 & app2)

The point is node.js has a mechanism for dealing with this already and it's awesome. Just combine it with the 'private not on NPM' trick and you are good to go.

In short a:


From app A or B would cascade upwards until it found the module - regardless if it lived lower down or higher up. Indeed - this lets you hot-swap the location without changing any of the require(...) statements.

node.js module documentation

share|improve this answer
When I tried this, any modules required by the shared modules could not be resolved. In your structure, it looks like the highest node_modules folder has both private (checked into source control) and public (npm install'd - not checked in) modules. I don't normall check public modules into source control - how did you get around this? –  Adam C May 4 '13 at 21:19
add comment

Node recommends using npm link for creating your own node.js packages locally and then making them available to other applications. It's a simple four-step process.

Typical procedure would be to first create the package with the following structure

  | index.js
  | package.json

Typical implementation of these files would be


  exports.world = function() {
     return('Hello World');


    "name": "hello",
    "version": "0.0.1",
    "private": true,
    "main": "index.js",
    "dependencies": {
    "engines": {
    "node": "v0.6.x"

'private:true' ensures that npm will refuse to publish it to the repository. This is a way to prevent accidental publication of private repositories.

Next navigate to the root of your application folder, run npm link to link the file globally so it can be used in other packages.

Now to use this package in another app, say hello-world with the following directory structure

 | app.js

navigate to the hello-world folder and run

 npm link hello

Now use it like any other npm package as


  var http = require('http');
  var hello = require('hello');

  var server = http.createServer(function(req, res) {
share|improve this answer
How does this work when deploying to a PaaS environment such as Heroku or Nodejitsu? –  Adam C May 4 '13 at 21:21
npm link won't work in a PaaS environment. Heroku honours node modules that are pushed in with your code. So that might be an option. –  almypal May 5 '13 at 3:05
That's what I don't get - if you deploy to Heroku from git, you don't check your node_modules in. Also, that would imply that you copy you shared code into the node_modules folder before you check in. Which seems cumbersome and error prone. Or am I missing something? Thanks! –  Adam C May 6 '13 at 4:49
That seems the only way out. The npm link option is only available if you have access to the remote terminal over ssh... as in AWS or Rackspace –  almypal May 6 '13 at 7:08
Ok, I think the way to go is using dependencies defined as git repos or tarballs, then use npm link to make life easier during development... Thanks for your thoughts! –  Adam C May 7 '13 at 6:30
add comment

Just use the correct path in your require call

For example in server.js that would be:

var moduleName = require('../shared_lib/moduleName/module.js');

Its Important to know that as soon as your path is prefixed with '/', '../', or './' the path is relative to the calling file.

For further information about nodes module loading visit: http://nodejs.org/docs/latest/api/modules.html

share|improve this answer
But if I do that, and then that module tries to require a module that comes from npm, it gets confused and gives errors. –  rob Jul 1 '12 at 2:29
add comment

If you check out the node.js docs, you'll see that Node.js understands the package.json file format as well, at least cursorily.

Basically, if you have a directory named foo, and in that directory is a package.json file with the key-value pair: "main": "myCode.js", then if you try to require("foo") and it finds this directory with a package.json file inside, it will then use foo/myCode.js for the foo module.

So, with your directory structure, if each shared lib has it's own directory with such a simple package.json file inside, then your apps can get the shared libs by:

var lib1 = require('../shared_lib/lib1');
var lib2 = require('../shared_lib/lib2');

And that should work for both of these apps.

share|improve this answer
add comment

Your Answer


