What to use instead of require.paths?

Recent node docs say changing require.paths is bad practice. What should I do instead?

+10
source share
4 answers

I believe the problem is that it can be modified many times at run time, and not just installed. This, obviously, can be misleading and causes some rather strange errors. In addition, if individual packages change the path, the results are applied globally, which is very bad and contradicts the modular nature of the node.

If you have several library paths of your own, the best solution is to set the NODE_PATH environment variable before starting node. Node then selects this at startup and automatically applies it.

+5
source share

I keep related models in the same directory or subdirectory using:

 var x = require('./mod/x'); 

In case this is an external module, I install it using npm, which correctly installs the module in NODE_PATH.

I have never changed require.paths.

+1
source share

take a look at https://github.com/patrick-steele-idem/app-module-path-node ; you can add a directory to the require statements at the top level without affecting the path of the submodules.

+1
source share

If I'm not mistaken in my understanding, the main limitation of the current system is that for the namespace you are stuck without using folders for non-hierarchical dependencies.

What does this mean in practice ...

Note that you have x / y / z and a / b as well as a / b / c. If both a / b and a / b / c depend on z / y / z, you will eventually have to either specify this with respect to ( require('../../x/y/z') and require('../../../x/y/z') respectively), or make each individual node_module package. Otherwise, you can do terrible things with symbolic links or the like.

As far as I can tell, the only alternative is to use folders instead of namespace and organization, use file names such as:

  • abjs
  • abcjs
  • xyzjs
0
source share

All Articles