NODE_PATH, best practices

[Claudio Cicali]

How do you manage the NODE_PATH env variable?

Using npm for almost every module in my project I set a "runner" script up that exports NODE_PATH and then run node. Something like:

export NODE_ENV=development

if [ "${NODE_PATH}" = "" ]; then

  export NODE_PATH=$(npm -g root 2>/dev/null)

fi

node ${1}

My custom modules are in the node_modules directory of the project, so they are automatically discovered.

There is of course the possibility to add NODE_PATH to .bashrc or similar, but I prefer going through a more "dynamic" way (I might want to run node without the var set up).

Any thought?

--

Claudio Cicali

http://ccl.me

[Bradley Meck]

Generally I avoid using NODE_PATH since we use a very modular approach to projects and since the default path will grab all the global modules. Is there a reason you have external modules that are not global, as opposed to just including them in the module?

[Claudio Cicali]

Mmmh, my modules are all global (I use npm -g install). 

But, unless I set the NODE_PATH env, they are not seen.

[Dean Landolt]

On Tue, Aug 30, 2011 at 12:02 PM, Claudio Cicali <claudio...@gmail.com> wrote:

Mmmh, my modules are all global (I use npm -g install). 

But, unless I set the NODE_PATH env, they are not seen.

Yeah, "global" is a bit of a misnomer in npm 1.0 -- it only  means you can run a module's scripts from the cli. You still need to install the module locally for it to be accessible to a given project.

[Vojto Rinik]

Can you please tell me more about your modular approach?

I'm struggling with organizing my code and I should like to see how other people do it. 

On Aug 30, 2011, at 10:09 AM, Bradley Meck wrote:

Generally I avoid using NODE_PATH since we use a very modular approach to projects and since the default path will grab all the global modules. Is there a reason you have external modules that are not global, as opposed to just including them in the module?

--
Job Board: http://jobs.nodejs.org/
Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
You received this message because you are subscribed to the Google
Groups "nodejs" group.
To post to this group, send email to nod...@googlegroups.com
To unsubscribe from this group, send email to
nodejs+un...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en

[Bradley Meck]

Any module that I require that is not in my module itself is listed in my package.json and generally does not produce side effects when they are required.

All my modules are installed locally in node_modules (as opposed to globally) in order to prevent unintentional side effects of upgrading a global module that works in one of my modules but upgrading breaks a different one of my modules.

If I need to use an executable from a require, I install it via NPM and use node_modules/.bin with require('child_process')

Doing all of this allows for very strict compartmentalization and not dependency on the system environment being set up for me beyond an `npm install`.

If I am doing dev on one of my modules and need to test the new dev module against another module that requires it I use `npm link devModule` rather than deploying out stuff to NPM. Finally, when a deploy is ready I remove the link and install from latest to ensure what I pushed to NPM still works.

Basically, do everything you can to ensure the user doesn't need to set up the environment and you don't change the environment, because they will do it wrong, and you will get support issues about it.