Consider the following structure where x depends on a and b and where a peerDepends on b:
.
├── README.md
├── node_modules
│ ├── a
│ │ ├── README.md
│ │ ├── a.js
│ │ └── package.json
│ └── b
│ ├── README.md
│ ├── b.js
│ └── package.json
├── package.json
└── x.js
This actually works fine and executes. In code, x.js requires a.js, which in turn requires b.js.
OK, so now I want to do some development on a so I clone its repo to a workspace on my disk and in x I do an npm link <path to repo clone> so that changes I make to a are reflected when I test x and a together.
The tree now looks like this:
.
├── README.md
├── node_modules
│ ├── a -> /usr/local/share/npm/lib/node_modules/a
│ └── b
│ ├── README.md
│ ├── b.js
│ └── package.json
├── package.json
└── x.js
and npm ls detects the link:
x@0.0.0 /Users/greg/temp/peer-dep-test/x
├── a@0.0.0 -> /Users/greg/temp/peer-dep-test/a
└── b@0.0.0
This, however, does not execute. a will no longer find b as a peer dependency since it is not physically located as a peer of b.
$ node x.js
module.js:340
throw err;
^
Error: Cannot find module 'b'
This is a problem with Node and not npm, though, since Node looks for b from its actual path:
$ pwd
/Users/greg/temp/peer-dep-test/x
$ NODE_DEBUG=module node x.js
...
Module._load REQUEST b parent: /Users/greg/workspace/a/a.js
looking for "b" in [
"/Users/greg/workspace/a/node_modules",
"/Users/greg/workspace/node_modules",
"/Users/greg/node_modules",
"/Users/node_modules",
"/node_modules",
"/Users/greg/.node_modules",
"/Users/greg/.node_libraries",
"/usr/local/Cellar/node/0.8.19/lib/node"]
module.js:340
throw err;
^
Error: Cannot find module 'b'
As a workaround I can explicitly add the node_modules directory of x when running, which will make symlinked dependencies of x find their peers:
$ NODE_PATH=./node_modules node x.js
Wow thank you - this is a great workaround!