"npm ls -g" produces no output if global node_modules includes invalid symlink

[mcnameej]

Environment: node v4.0.0 on Windows 7 X64.

At some point in the past, I used "npm link" and it created a symlink under %appdata%\npm\node_modules. The directory it linked to has since been renamed, so the link target is now invalid.

With npm v2.14.3, "npm ls -g" shows an empty module name for the bad symlink, but otherwise works...

C:\Users\xxxx\AppData\Roaming\npm
├── babel@5.8.23
├── grunt-cli@0.1.13
├── gulp@3.9.0
├──
└── webpack@1.12.1

npm v3.3.3 displays absolutely nothing. No directory listing and no error message.

I removed the obsolete symlink, and npm v3 started working.

[75lb]

same for me on 3.3.3, Mac OSX.. no output from npm ls -g until i clear dead symlinks using brew prune

[dkebler]

Same issue for me on ubuntu 14.04 with npm 3.3.12 and node 5.

I seem to recall way back using npm link so maybe it's the same reason. Not quite sure where on linux install this link will reside that needs to me removed. Any help?

[dkebler]

Little rtfm and I tracked it down in /usr/local/lib/node_modules
https://docs.npmjs.com/files/folders

Yes there is a sym link there to my personal module. I moved it out of the directory and bingo the
npm ls -g works. just like @mcnameej says.

But HEY! I want to keep that link to my module so if I recreate it with V3.x (that was created in v2) will all be ok?

[raineorshine]

Any progress on this? This is causing some nasty consequences down the line in projects that depend on npm, like npm-check-updates.

Is there anything I can do to help?

[raineorshine]

Hello, checking in again. Impacts npm-check-updates. Let me know if I can assist in any way.

[zkat]

Hey! So, I removed the big-bug label cause we reserve that for crashers and incorrect installs. Since this is an issue with npm ls that doesn't affect installation, it's just a bug.

That said! We'd welcome a patch for this, @raineorshine. #12865 is a related-but-not-the-same PR open that involves links in npm ls, so you could at least refer to it to see what sort of stuff to look for, how to write tests for it, etc. Let me know if there's any other questions you have about how to pull this off.

And thank you for offering!

[raineorshine]

Thanks! Limited in time on open source still, but am watching this issue closely.

[branb]

Just in case it may be of help, here is my system information under which this bug occured as well:

uname -a
Linux myhost 4.13.0-32-generic #35~16.04.1-Ubuntu SMP Thu Jan 25 10:13:43 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

lsb_release -a
No LSB modules are available.
Distributor ID:	LinuxMint
Description:	Linux Mint 18.3 Sylvia
Release:	18.3
Codename:	sylvia

npm config list
; cli configs
user-agent = "npm/3.8.8 node/v4.4.3 linux x64"

nvm debug
nvm --version: v0.31.0
$SHELL: /bin/bash
$NPM_CONFIG_PREFIX: ''
nvm current: v4.4.3
which node: $NVM_DIR/versions/node/v4.4.3/bin/node
which iojs: 
which npm: $NVM_DIR/versions/node/v4.4.3/bin/npm
npm config get prefix: $NVM_DIR/versions/node/v4.4.3
npm root -g: $NVM_DIR/versions/node/v4.4.3/lib/node_modules

I can provide more details if it's desired.

[james-gibson]

I did a little bit of digging and noticed that the errors are ignored when operating on the global dir. This was added 3 years back so I'm not sure if this is intended behavior or not.

See 0bb08c8#diff-0d4754093eef60f5a70da5b0c6951cc6R148 and 0bb08c8#diff-0d4754093eef60f5a70da5b0c6951cc6R443