Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1271290

Summary: `npm ls -g` outputs false errors
Product: Red Hat Software Collections Reporter: Miroslav Hradílek <mhradile>
Component: npmAssignee: Tomas Hrcka <thrcka>
Status: CLOSED ERRATA QA Contact: Miroslav Hradílek <mhradile>
Severity: low Docs Contact:
Priority: low    
Version: nodejs010CC: kanderso, lkuprova, thrcka
Target Milestone: alphaKeywords: Reopened
Target Release: 2.1   
Hardware: Unspecified   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
The broken symbolic link pointing to the inherits@2 directory also caused that the npm package manager was unable to traverse all modules installed globally. Consequently, using the "npm ls -g" command to list global packages details failed with an error message. With this update, the symlink logic for inherits@2 has been disabled, and "npm ls -g" now works as expected. Note that packages other than npm are unaffected.
Story Points: ---
Clone Of: 986422 Environment:
Last Closed: 2016-02-22 14:22:46 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Miroslav Hradílek 2015-10-13 14:33:53 UTC
Collection packages as of 2.1 are also affected:
nodejs010-npm-1.4.28-5.el7
nodejs010-npm-1.4.28-5.el6
nodejs010-nodejs-inherits-2.0.0-7.el7
nodejs010-nodejs-inherits-2.0.0-7.el6

+++ This bug was initially created as a clone of Bug #986422 +++

Description of problem:
When I try to install npm with yum, it pulls in both

  dependency: npm(inherits) >= 1
   provider: nodejs-inherits1.noarch 1.0.0-11.fc19
   provider: nodejs-inherits.noarch 2.0.0-3.fc19
  dependency: npm(inherits) < 2
   provider: nodejs-inherits1.noarch 1.0.0-11.fc19
   provider: nodejs-inherits.noarch 1.0.0-7.fc19

when I check in /usr/lib/node_modules there is a link from inherits -> inherits@2.

When I then do a npm list -g, I get the errors shown in the attachment "npm_list_errors"



Version-Release number of selected component (if applicable):


How reproducible: always 


Steps to Reproduce:
1. Yum install npm
2. npm list -g to view the list of installed modules along with the errors

Actual results:
I get the list of errors/conflicts as shown in the attachment "npm_list_errors"

Expected results:
I expected no errors or conflicts in the list of installed modules

Additional info:

--- Additional comment from T.C. Hollingsworth on 2013-07-19 16:33:10 EDT ---

(In reply to relaxcold from comment #0)
> Description of problem:
> When I try to install npm with yum, it pulls in both
> 
>   dependency: npm(inherits) >= 1
>    provider: nodejs-inherits1.noarch 1.0.0-11.fc19
>    provider: nodejs-inherits.noarch 2.0.0-3.fc19
>   dependency: npm(inherits) < 2
>    provider: nodejs-inherits1.noarch 1.0.0-11.fc19
>    provider: nodejs-inherits.noarch 1.0.0-7.fc19

This is intended, and matches upstream's bundled modules:
[tc@zathras]~/dev/npm/node_modules% find -path "*/inherits/package.json" -exec grep '"version"' {} \;
  "version": "2.0.0",
  "version": "1.0.0",

There's nothing wrong with this, it's  one of the reasons node supports multiple levels of node_modules directories.  ;-)

> when I check in /usr/lib/node_modules there is a link from inherits ->
> inherits@2.
>
> When I then do a npm list -g, I get the errors shown in the attachment
> "npm_list_errors"

npm checks things differently depending on what level in the hierarchy it's in and gets it wrong sometimes.  I'm looking into it.

For example, in your output there's:
>  ├─┬ block-stream.6
>    │ └── UNMET DEPENDENCY inherits *

But you'll notice if you `cd` in there that `npm ls` is happy:

[tc@zathras]/usr/lib/node_modules/block-stream% npm ls
block-stream.6 /usr/lib/node_modules/block-stream
└── inherits.0 -> /usr/lib/node_modules/inherits@1

Only `npm ls -g` is confused, require() still works flawlessly and `npm ls` works fine everywhere else in the filesystem, so npm works just fine (besides the incorrect errors it spits out).  The errors can be safely ignored for now, and they'll get shut up soon enough. ;-)

Sorry for the trouble, and thanks for the report!

--- Additional comment from  on 2013-07-22 12:11:25 EDT ---

Thank you for the feedback on the issue.

I was unsure if the conflicts npm found could cause problem in the nodejs programs, but I understand you as this is not the case.

--- Additional comment from Jason Woods on 2015-01-26 10:02:55 EST ---

I am seeing this issue with RedHat 6.6 machine

$ npm list -g
npm ERR! missing: inherits@*, required by undefined@undefined
npm ERR! missing: inherits@*, required by block-stream.7
npm ERR! missing: inherits@*, required by fstream.24
npm ERR! missing: inherits@*, required by fstream-ignore.7
npm ERR! missing: inherits@*, required by fstream-npm.5
npm ERR! missing: inherits@*, required by glob.6
npm ERR! invalid: inherits.0 /usr/lib/node_modules/inherits@2
npm ERR! missing: inherits@*, required by npmconf.2
npm ERR! missing: inherits@*, required by tar.18
npm ERR! not ok code 0

$ cat /etc/redhat-release
Red Hat Enterprise Linux Server release 6.6 (Santiago)

If I remove the symlink at /usr/lib/node_modules/inherits (which points to inherits@2), and rename the directory /usr/lib/node_modules/inherits@2 to inherits, everything works again. Looks like npm list -g does not support symlinks

--- Additional comment from Jason Woods on 2015-01-26 10:04:13 EST ---

Relevant package that has the symlinks and causes this problem is "nodejs-inherits-2.0.0-4.el6.noarch"

--- Additional comment from Eric Work on 2015-02-14 02:44:52 EST ---

I observe the same issue on Fedora 21.  The fix was the procedure Jason described in comment #8.  When I remove the symlink and move the real directory to the location of the symlink I get no warnings at all when I do "npm ls -g".  Maybe this should be fixed in nodejs-inherits?

--- Additional comment from Tom Hughes on 2015-02-14 03:06:35 EST ---

Removing the symlink is not the answer - that is an essential part of our packaging scheme for node modules that have multiple versions packaged. It points to the latest version so that, for example, "npm link inherits" picks up the latest version.

Comment 5 errata-xmlrpc 2016-02-22 14:22:46 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHEA-2016-0285.html