Node pitfalls 3: this is not the file you want

In Node, each module has its own copy of its dependencies, under its own node_modules directory. Each of those modules in turn can have its own dependencies under its own node_modules, and so on, in matryoshka doll fashion. This is not a bad way to deal with dll hell: module A can depend on a specific version of module B, and cohabitate within the same application with other modules that depend on another version of module B.

This can be a little confusing, of course, in particular if you’re debugging deep into this code: what version of B are you looking at? When you set a breakpoint into the wrong version, it can be very strange to see Node zap by without breaking. I’m not sure how to alleviate the problem, except by being aware of it, and by observing your stack traces in order to target the right file.

The same kind of confusion can happen when you are editing a module that others depend on. Of course, you should *never* edit anything inside of a node_modules folder: that’s npm’s turf. I routinely find myself doing it by mistake however. Here’s how it happens: if module B is actually installed from another folder in the application, it’s legitimate to edit that module’s files. A Grunt script typically makes sure that changes to B’s source trigger the reinstallation of the module into any other that depends on it. The tricky part is that if you were debugging into one of B’s files as included in another module, the file where you found a bug, and that you are likely to want to edit, is just a copy. If you edit it, you will only fix the problem within that module, and only until next time it gets reinstalled. Hair pulling and WTF usually ensues.

The solution, once again, is discipline: don’t assume that the file where you saw the bug during your debug session is the real thing, and not a copy deep into the rabbit’s hole. Systematically re-open the file from your IDE’s project explorer view, to make sure you’re editing the right file.


  • Yeah it's a decent solution for dependency management when you don't have OS path length restrictions.

    For reasons I'm not going into here, I needed to commit all dependent third-party modules to my repo; this was fine, except Git continually failed when branch switching and the dependencies changed because it couldn't write out the files it needed to change due to Windows' path length limit. Interesting that node itself doesn't experience this issue.

    I worked around it by running 'npm dedupe' and also manually digging in and moving deep dependencies further up the tree. Much annoy!

  • @Rhys: of course I don't know the specific reasons why you'd be including node_modules in your repo, but that is explicitly called out as bad practice (, so I'd first try to stop implementing that bad practice before I attempt to mitigate its consequences.

Comments have been disabled for this content.