Thanks for the report! What does nvm deactivate ; nvm debug ; echo $PREFIX ; echo $NPM_CONFIG_PREFIX print out?

and the env vars?

Thanks! so, clearly you don't have an npm prefix set.

Are you by chance using oh-my-zsh? That tends to set tons of opts that nvm has to manually account for.

Yeah, I am.. I could manually set it, I assume? How do I go about that?

If you try to set the "prefix" that will break nvm.

As a temporary workaround, you can do nvm use --delete-prefix v0.12.7, but this is a bug specifically with omz. I'll have to figure out which option to unset when doing the comparison.

Okay, let me know if I can help with anything!

Could you provide the output of setopt as well? From there I should be able to try to debug it.

Thanks! I'll take a look at this asap.

One more thing that could be interesting: this is a brand new installation of El Capitan; I didn't have this issue before on Mavericks (I also used oh my zsh on Mavericks)

Good to know - I don't have an El Capitan machine to test on just yet.

If you have anything else I should test for you, just let me know.

I definitely started noticing these issues after upgrading to El Capitan.

@mikepaggi you're also on zsh? are you using oh-my-zsh?

I'm also getting this issue on Yosemite:

nvm is not compatible with the npm config "prefix" option: currently set to "/usr/local/Cellar/nvm/0.27.1/versions/node/v4.1.1"
Run `nvm use --delete-prefix v4.1.1 --silent` to unset it.

Once I run nvm use --delete-prefix v4.1.1 --silent it starts working normally, but I have to do it every time I open a new session.

@rudeworks nvm is utterly unsupported on homebrew - please brew uninstall that, and install using the proper curl command in the readme, and see if you're still having issues?

I get the same error on Yosemite:
nvm is not compatible with the npm config "prefix" option: currently set to "/Users/cristik/.nvm/v0.10.38" Runnpm config delete prefixornvm use --delete-prefix v0.10.38 --silentto unset it.
and I installed using the curl command in readme.

@ckiss thanks - also on zsh?

FWIW I'm also getting this on Arch Linux also with zsh, with nvm installed both via curl and by manually cloning and sourcing nvm.sh in my .zshrc.

I hadn't updated nvm in a while, but I did just notice that the last 'good' tag (i.e. no error shown) was v0.26.1. I'll see if I can find the actual commit where this begins.

Thanks - I'm quite certain it's simply the commit where I added this check, which suggests that the check doesn't work properly in zsh. @jaromero, can you also confirm whether you are or are not using oh-my-zsh?

Hi,
Like some of the others, I too was only experiencing this issue in vscode. I am on version 0.33.11. Afteer some tinkering around, I unchecked the Terminal > Integrated > Inherit Env option. Here is the corresponding setting in json:
"terminal.integrated.inheritEnv": false
This seemed to have fixed the issue for me.

Using npm config delete prefix before loading nvm doesn't change the output of npm config get prefix. How can I ensure the prefix is deleted before loading nvm?

for vscode (or any editor), i believe you'd need to find a way to configure it to use a login shell.

It's worth noting that the default "user settings" of vscode include the -l flag (which makes it a login shell) in terminal.integrated.shellArgs.osx.

I tried setting it explicitly, but no dice:

"terminal.integrated.shell.osx": "/bin/zsh",
"terminal.integrated.shellArgs.osx": ["-l"],

Any other ideas? This only happens in vscode for me.

• macOS Mojave v10.14.1
• nvm v0.33.11

Issue solved

Upgrading nvm to v0.34.0 has fixed the issue for me. 🎉

I have the same problem. and resolved as follows.

$ vi ~/.bash_profile

...

export NVM_DIR="/User/Falsy/.nvm"
[ -s "$NVM_DIR/nvm.sh" ] && \. "$NVM_DIR/nvm.sh"  # This loads nvm
[ -s "$NVM_DIR/bash_completion" ] && \. "$NVM_DIR/bash_completion"  # This loads nvm bash_completion

export PATH=/Users/Falsy/.nvm/versions/node/v12.14.0/bin:$PATH

(Where 'Falsy' is the my computer username.)

@falsy assuming whoami prints out Falsy, and echo $HOME also matches the capitalization, I'm not sure why you're running into that problem. You should not have to manually configure the PATH.

@ljharb that's right. this is not an exact solution. i have two macOS computers. this problem only occurs on one of them. the difference between the two computers is that the computer in question is logged in as a newly added user instead of an existing admin user.
i'm not exactly sure what caused this problem. i hope my guess helps a bit.
finally, i'm always using nvm well. thank you.

Upgrading to the latest version of nvm fixed the issue for me (0.35.3). As a precaution, I removed the ~/.nvm directory and installed fresh versions of Node.js using the updated nvm.

See https://github.com/nvm-sh/nvm for instructions.

@fabdrol have you solved your issue, or is it still a problem?

I am having the same issue on an Amazon Linux 2 cloud machine. I am also using zsh and oh-my-zsh.

Lots of people above have provided solutions to this including reinstall node, uninstall brew node, reinstall nvm etc.

But really the only essential step you need to do is to remove the wrong npm reference applied before your nvm script path settings.

Most of the time this is /usr/loca/bin/npm

Which means you just need to do rm /usr/loca/bin/npm and restart your terminal.

If this doesn't solve the problem, you can run which npm before your nvm path setting script to find out what is it, and just remove it.

Upgrading to the latest version of nvm fixed the issue for me (0.35.3). As a precaution, I removed the ~/.nvm directory and installed fresh versions of Node.js using the updated nvm.

See https://github.com/nvm-sh/nvm for instructions.

Updating fixed this issue for me as well.

Hello,
On my side, all of these solutions did not solve my problem.
But I finally find it, my $HOME value was /Users/alexandre while the real path was /Users/Alexandre. So I first hardcoded the NVM_DIR var with the matching case, and as it was ok I finally renamed by home folder all in lower case to avoid other similar problems.
Hope it helps too...

I met this issue as well, and resolved it by added the following lines to ~/.zshrc file.

export NVM_DIR="$HOME/.nvm"  
[ -s "$NVM_DIR/nvm.sh" ] && \. "$NVM_DIR/nvm.sh"  # This loads nvm    
[ -s "$NVM_DIR/bash_completion" ] && \. "$NVM_DIR/bash_completion"  # This loads nvm bash_completion
export PATH=$HOME/.nvm/versions/node/v12.16.3/bin:$PATH

• OS: Ubuntu 18.04
• Terminal: on-my-zsh
• NVM: 0.35.2

@vegetabill specifically, nvm does not support the home dir being a symlink (and many other tools may not either). I'd suggest to your org's dev ops team that they use a hard link or a mount, rather than a symlink.

I'm on FreeBSD, where /home is a symlink to /usr/home by default, effectively triggering the error regarding the prefix, probably for each and every FreeBSD installation (and potentially other Unix flavors) out there.

Disallowing symlinks within one's home path thus doesn't seem to be a very portable way of looking at things.

Maybe stuff like readlink -f and/or pwd -P might help to create more portable scripts.

@olivermg that's new information for me, and quite unfortunate, but I'm very surprised that over the 6-8 years nvm has been around, no FreeBSD user has reported this before :-/

See #2143 and #617 for things relevant to symlinks.

@ljharb For more info, I've just installed a few recent BSDs in VMs:

All the following FreeBSD installations set /home to a symlink to /usr/home, while also setting $HOME to /home/myuser (chshing from the default shell sh to bash does not seem to make a difference to the value of $HOME):

• FreeBSD 12.1 default installation (thus UFS filesystem)
• FreeBSD 12.1 with ZFS filesystem instead of UFS
• FreeBSD 11.4 default installation (thus UFS filesystem)
• FreeBSD 13-CURRENT default installation (thus ZFS filesystem)

The following BSDs don't seem to use symlinks in home paths though:

• OpenBSD 6.7
• NetBSD 9.0

@ljharb Btw, if it's coming in handy for you I can start working on a PR regarding this issue (i.e. supporting OSes that do use symlinks in home paths).

Moreover, this is probably a new distinct issue, as it is not related to zsh.

UPDATE: I understand there is already a PR going into this direction in #2143 . Let's see if your request for finishing that PR actually triggers a response ;-) . If not I'll maybe look into it.

@olivermg it would also be awesome if you wanted to just comment on #2143 with a link to your own branch that builds off of it - i can easily pull in those commits, even if the OP doesn't respond. I'd love to improve the workflow here, just because nvm hasn't worked with symlinks for awhile doesn't mean it doesn't suck that it doesn't :-)

Btw, just noticed that Fedora Silverblue also uses symlinks in home paths:

$ ls -lad /home
lrwxrwxrwx. 3 root root 8 Feb 22  2020 /home -> var/home

UPDATE: However, it doesn't seem to be triggering the prefix error message (like e.g. on FreeBSD), as Fedora seems to set $HOME to the physical path (so without a symlink in it).

@sricharankrishnan remove the prefix line in ~/.npmrc

Cannot change root .npmrc as it is locked for change.

@AnshulSurana that's not the root npmrc, that's your user npmrc, and you should always have full control of anything in ~. If you can't remove that line, then unfortunately you can't use nvm, because the two things are incompatible.

I do not use oh-my-zsh, I use ZimFW, but I'll still tag along because I think it's related.

My flavor of this is pretty damn weird. When I open a terminal, I get:

grep: Desktop: Is a directory
grep: Downloads: Is a directory
...etc

This also happens on TTY, with no graphical server running at all.

In specific directories, I get weird stuff, like:

grep: node_modules: Is a directory
grep: out: Is a directory
grep: src: Is a directory
grep: static: Is a directory 
(eval):1: command not found: forge.config.js
nvm is not compatible with the "README.md:- [`forge.config.js`](./forge.config.js): decides which packages are used by Electron Forge. In particular, it sets the exporters (Windows, Mac, Linux, ...)" environment variable: currently set to ".md:- [](./forge.config.js): decides which packages are used by Electron Forge. In particular, it sets the exporters (Windows, Mac, Linux, ...)"
Run `unset README.md:- [\`forge.config.js\`](./forge.config.js): decides which packages are used by Electron Forge. In particular, it sets the exporters (Windows, Mac, Linux, ...)` to unset it.

Of course, the sentence

- [`forge.config.js`](./forge.config.js): decides which packages are used by Electron Forge. In particular, it sets the exporters (Windows, Mac, Linux, ...)

is part of my README.md and describes the project's architecture.

The string forge.config.js only exists in the README.md and as a config key in `package.json.

> grep -R "forge.config.js" --exclude-dir node_modules
package.json:    "forge": "./forge.config.js"
README.md:- [`forge.config.js`](./forge.config.js): decides which packages are used by Electron Forge. In particular, it sets the exporters (Windows, Mac, Linux, ...)

If I remove that sentence from the README, then nvm tells me this:

nvm is not compatible with the "package.json:    "forge": "./forge.config.js"" environment variable: currently set to ".json:    forge: ./forge.config.js"

If I remove that, then I only get the directories issues described above. Removing only the line in package.json isn't sufficient, however.

So nvm is deciding on its own to... parse the README.md, extract that string for some reason, then eval it? Then decide that there's an environment variable equal to the whole line?

Notice the environment variable's name starts with README.md: ... but it's set to .md: ...

I can confirm these issues come from nvm, because if I do not source nvm.sh, I get none of this. Using bash fixes the problem too, so this some kind of mix between nvm and zsh.

Apart for these annoying notices, nvm is working as expected, as far as I can tell.

This issue was resolved in v0.37.0 with #2317

@Xananax would you mind filing that as a new issue, with the full issue template filled out?

This turned out to be the fix for me. Uninstalled npm and the error was gone. Now to re-install it and see if I'm in the clear.

Lots of people above have provided solutions to this including reinstall node, uninstall brew node, reinstall nvm etc.

But really the only essential step you need to do is to remove the wrong npm reference applied before your nvm script path settings.

Most of the time this is /usr/loca/bin/npm

Which means you just need to do rm /usr/loca/bin/npm and restart your terminal.

If this doesn't solve the problem, you can run which npm before your nvm path setting script to find out what is it, and just remove it.