Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP

Loading…

Set the NODE_PATH variable when activating node #97

Closed
wants to merge 1 commit into from

8 participants

@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.

@caio caio Set the NODE_PATH variable when activating node
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.
68f57ac
@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.
@panos-kosmidis

@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
@caio caio closed this
@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
Owner

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
Owner

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 :+1: 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
Collaborator

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
Collaborator

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
Collaborator

Sounds good, thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Commits on Jan 19, 2012
  1. @caio

    Set the NODE_PATH variable when activating node

    caio authored
    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.
This page is out of date. Refresh to see the latest.
Showing with 1 addition and 0 deletions.
  1. +1 −0  nvm.sh
View
1  nvm.sh
@@ -197,6 +197,7 @@ nvm()
export MANPATH
export NVM_PATH="$NVM_DIR/$VERSION/lib/node"
export NVM_BIN="$NVM_DIR/$VERSION/bin"
+ export NODE_PATH="$NODE_PATH:$NVM_DIR/$VERSION/lib/node_modules"
echo "Now using node $VERSION"
;;
"run" )
Something went wrong with that request. Please try again.