Nvm: $NODE_PATH is not being set, so it can not find global modules

[snimavat]

For whatever reasons, nvm is not setting correct NODE_PATH, and hence my builds can not find the globablly installed modules.

my app does this require('ibrik') but it fails, even if the ibrik is installed globally

I think this is same problem as http://stackoverflow.com/questions/27876557/node-js-configuring-node-path-with-nvm

Am i supposed to set it manually ?

MacBook-Pro:coffee sudhir$ nvm ls
->       v6.3.1
default -> 6.3.1 (-> v6.3.1)
node -> stable (-> v6.3.1) (default)
stable -> 6.3 (-> v6.3.1) (default)
iojs -> N/A (default)
lts/* -> lts/argon (-> N/A)
lts/argon -> v4.4.7 (-> N/A)
MacBook-Pro:coffee sudhir$ nvm use 6.3.1
Now using node v6.3.1 (npm v3.10.3)
MacBook-Pro:coffee sudhir$ which npm
/Users/sudhir/.nvm/versions/node/v6.3.1/bin/npm
MacBook-Pro:coffee sudhir$ which node
/Users/sudhir/.nvm/versions/node/v6.3.1/bin/node
MacBook-Pro:coffee sudhir$ echo $NODE_PATH
<EMPTY>

MacBook-Pro:coffee sudhir$ npm ls -g -depth 0
/Users/sudhir/.nvm/versions/node/v6.3.1/lib
├── [email protected]
├── [email protected]
├── [email protected]
├── [email protected]
├── [email protected]
└── [email protected]

This is my exact problem - https://github.com/karma-runner/karma-cli/issues/22
Not sure if its problem because of nvm or its a karma bug

[ljharb]

This is intentional. NODE_PATH should never be set, and global modules both are not requireable by default, and should never be required. Something you require is a dependency, and thus, must be installed locally.

[snimavat]

Doesnt work even when i have ibrik installed locally..

[ljharb]

@snimavat when it's locally installed, you should use an npm run-script so that it sets up the PATH for you. Alternatively, ./node_modules/.bin/ibrik should work. *if it's a binary. if it's require()d, it should definitely work when installed locally.

[snimavat]

I will tryout and let u knw, this is the only module which doesnt work... other locally installed works just fine..

[ljharb]

@snimavat according to https://npmcdn.com/[email protected]/package.json there's no "main" - so that entire package is not requireable. It is _only_ a command-line tool.

[snimavat]

Crazy.. i am not a node expert, just trying to get coverage for the coffee files, and karma coverage examples used it the same way as i posted above...
https://github.com/karma-runner/karma-coverage/blob/master/examples/coffee/karma.conf.coffee

This is strange, but this setup works on other machine..

Note sure where this issue belongs to.. here, or karma, or karma-coverage..

[ljharb]

It looks like v1 did in fact have a "main" - https://npmcdn.com/[email protected]/package.json - so I think you're just using the wrong version of ibrik. I'd file the issue on karma-coverage - it's definitely not related to nvm.

[snimavat]

Thansk for clarifying, karma-coverage asks to use ibrik 2.. i will try to get help from them.. thanks

[illegalnumbers]

question on this - shouldn't / couldn't NODE_PATH get set for repl usage?

[illegalnumbers]

otherwise you can't really include global modules easily when using a REPL with nvm unless you do some hackery. sorry to reanimate a dead thread...

[ljharb]

@illegalnumbers you shouldn't be including global modules ever under any circumstances. If you want to play with something in a repl, install it locally, and then it'll be available to require.

[illegalnumbers]

why though? sometimes it does make sense to install and use global dependencies outside of the scope of a project especially if you're using it in a repl. there are many points of common functionality from parsing files of specific types to outputting in specific ways that could be common. it feels rather arbitrary to say to never use a part of npm.

[ljharb]

No, it never does make sense to do that; if it's required, it's a dependency, and it should be installed locally.

[illegalnumbers]

local to what though that's the question - it's not a project it's just a repl. it's a global usage area

[ljharb]

What use case do you have for playing with require that isn't going to end up being a project?

[illegalnumbers]

exploratory testing a new module or comparing and contrasting between usage, using something for a script that isn't part of the project (parsing files with a syntax that is less terrible than doing bash scripting), etc

[ljharb]

npm install --no-save new-module && node; as for the script, if it requires anything, it'd need a package.json to be able to be reproducible on another machine, so it's a bad idea to use globals for that too.

[illegalnumbers]

TIL --no-save which i think would fulfill what I needed for that particular use case and true, but I guess the prerequisite to what I was thinking would be that you aren't putting as part of the project and just running it as a one off

[maxatwork]

This breaks various plugins for editors, for instance, vim-comb - it uses csscomb, which is installed globally, because it's not a dependency of a particular project, but just a developer's tool, and can be used in different ways (from editor, from precommit hook or from whatever else). requireing csscomb is just a way to run it, not a dependency.

[ljharb]

@maxatwork if it’s requireable in a project, it is a dependency of a project, full stop. Separately, global things are never requireable, only runnable as command line tools. If an editor wants to do something absurd like require something that isn’t a dependency of the editor, it’d be the editor’s responsibility to employ hacks to make that work, not nvm’s.

[dustinaleksiuk]

I found this thread because I have a requirement to use the appdynamics node module. The npm install for that module pulls a version specific to the os. This breaks my shrinkwrap file because it hashes the module and it's always different between windows, mac, and linux. I can either install it globally, or I have to set the user-agent when I build so that it pulls the version for the server I'm deploying to. It's a mess. I was exploring using require with a global module for this specific package.

[ljharb]

@dustinaleksiuk typically using a shrinkwrap file also means every consumer has to be on the same OS (when you have compiled deps).

[seantcanavan]

Appreciate the concise schooling on global vs. local modules. Especially late at night and doubly so when trying to use global packages when nvm was designed specifically to only locally define the node environment.