Set the NODE_PATH variable when activating node

[caio]

When installing packages with npm using the global switch -g the package ends
up in the proper directory (i.e. .nvm/$VERSION/lib/node_modules), however node
is unable to require it since it somehow isn't searching on it's prefix.

This patch fixes this behavior by manually adding the node_modules dir to the
NODE_PATH variable.

[carter-thaxton]

I'm pretty sure this isn't the right way to circumvent npm, so you can require modules that are installed globally.
There's been a lot of discussion about this. I'd prefer nvm not pollute the NODE_PATH environment variable. I personally don't use it at all.

This is straight from the npm faq:

Q: I installed something globally, but I can't require() it

   Install it locally.

   The  global  install  location  is a place for command-line utilities to put their bins in the system
   PATH.  It's not for use with require().

   If you require() a module in your code, then that means it's a dependency, and a part  of  your  pro-
   gram.  You need to install it locally in your program.

[panosru]

@carter-thaxton I tend to disagree with you on that and apparently with npm itself as it seems.

I agree on the fact that when you need to require something in your project then it's a dependency of the project, yes that's true, from the other hand though if that what you need to require in project A you also need to require it in project B, C, D etc then it's a global dependency, most often web frameworks, mongo, redis, testing frameworks, validation frameworks and many others, so those that need to be required by multiple projects in my opinion I believe should be installed globally. Many of those global installed modules that need to be required by multiple projects also provide system wide binary apps, for instance less module is also required by projects but at the same time it provides lessc bin system wide and so do few other web frameworks that provide utilities like create controller, generate resource view etc

Indeed "polluting" NODE_PATH is not the best option but if it is the only option and treated carefully it could be used even as a temporary solution until there is another one which will be better from this one.

Hope you take it in consideration again, the I just run in similar issue as I posted in #119

Thanks

EDIT:
Also I confirm that this fixes my issue on #119

[carter-thaxton]

I found this behavior confusing at first, too, but I've since come to love it. Check out this FAQ for more. Perhaps 'npm link' is what you're looking for.

http://npmjs.org/doc/faq.html

On Jul 5, 2012, at 5:11 AM, Panagiotis [email protected] wrote:

@carter-thaxton I tend to disagree with you on that and apparently with npm itself as it seems.

I agree on the fact that when you need to require something in your project then it's a dependency of the project, yes that's true, from the other hand though if that what you need to require in project A you also need to require it in project B, C, D etc then it's a global dependency, most often web frameworks, mongo, redis, testing frameworks, validation frameworks and many others, so those that need to be required by multiple projects in my opinion I believe should be installed globally. Many of those global installed modules that need to be required by multiple projects also provide system wide binary apps, for instance less module is also required by projects but at the same time it provides lessc bin system wide and so do few other web frameworks that provide utilities like create controller, generate resource view etc

Indeed "polluting" NODE_PATH is not the best option but if it is the only option and treated carefully it could be used even as a temporary solution until there is another one which will be better from this one.

Hope you take it in consideration again, the I just run in similar issue as I posted in #119

Thanks

EDIT:
Also I confirm that this fixes my issue on #119

---

Reply to this email directly or view it on GitHub:
#97 (comment)

[ackalker]

echo "I smell a Wumpus" | sed -e 's/Wumpus/virtualenv/g'

...and I was being hopeful that nodejs and npm would put an end to those...(and also put that constricting snake out of business, for that matter) :-(
Must be something deeply philosophical about package dependency management, methinks. Something that appears to be practically unavoidable.

[creationix]

Regarding system-wide executables like lessc, nvm already supports those because they live in the same $PATH as the node binary itself. NODE_PATH is only needed if you want to require global libraries from local programs, which according to most the node core people (myself included) is a bad idea. I don't want nvm promoting such a practice.

Also, this is just a script in your environment. It's like part of your bashrc. When people post their bashrc files on github, if there is a part you disagree with, you don't try to convince them to change, you fork and keep your own custom copy. Do the same with nvm.

[atomless]

When using yeoman and it's various generators that feel like global packages rather than ones to install locally it's a real pain that these get installed into a version specific modules folder. Shouldn't globally installed packages be available globally rather than havign to reinstall everything when switching node version or worse as I am finding that I have switched node versions and now can't seem to update yeoman with npm as it appears to be unaffected either by npm update -g yo or even npm uninstall -g yo

[creationix]

If you want a custom and persistent NODE_PATH, just set it in your .profile or .bashrc in the line before you source nvm.

[atomless]

Thanks, yes I'd tried that. In the end what I discovered is that I had an existing couple of packages that I must have installed globally ages ago before I installed nvm. This meant that these packages were in my default PATH and once nvm was active were never effected by npm update or uninstall. The fix I found was to remove them from the folder in my default PATH then restart my terminal. Now I find the way nvm causes global packages to be installed per node version to be perfectly understandable and works fine.

[atomless]

Possibly worth mentioning in the docs, warning people before they install nvm that it's a good idea to npm uninstall any global packages as after installing nvm these will be unaffected by npm uninstall.

[ELLIOTTCABLE]

Just a 👍 to @atomless's suggestion. This bit me, too; spent a while trying to figure out why things were going haywire, before realizing that previously-installed -g binaries were being used instead of ones installed with nvm's npm.

A note post-install or similar would be grand, for future users. (=

[ljharb]

I'm happy to review a PR for that. If you have system global packages, the solution would be to nvm use system && npm uninstall -g foo if you wanted it uninstalled - I'm not sure how this could best be communicated upon nvm use, though.

[ELLIOTTCABLE]

(Which would you prefer, assuming I have the time to set aside to patching the docs: Just a mention in the README, or a notice on the install-script / first-run / something like that?)

[ljharb]

Definitely a mention in the readme - I'd also go for a notice - either once on "install", or, on-every-source as long as it can only do it when it detects global modules in the system npm root -g?

[ELLIOTTCABLE]

On-every-source seems like a bad plan. I don't see why we should proscribe having globally-installed modules; just making sure people are aware that they're splitting their module-set by nvm'ing.

I'll try and take a look in a couple days. <3

[ljharb]

Sounds good, thanks!

[Flackus]

Hey guys, looks like this no longer works in the current master :(
I see export of corresponding environment variable only in deactivate https://github.com/creationix/nvm/blob/master/nvm.sh#L1869

[ljharb]

@Flackus this was intentionally removed many versions ago. NODE_PATH should never be set, and global modules should never be requireable.