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.