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.

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