Bug 1271290 - `npm ls -g` outputs false errors
Summary: `npm ls -g` outputs false errors
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Software Collections
Classification: Red Hat
Component: npm
Version: nodejs010
Hardware: Unspecified
OS: Linux
low
low
Target Milestone: alpha
: 2.1
Assignee: Tomas Hrcka
QA Contact: Miroslav Hradílek
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-10-13 14:33 UTC by Miroslav Hradílek
Modified: 2016-02-22 14:22 UTC (History)
3 users (show)

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.
Clone Of: 986422
Environment:
Last Closed: 2016-02-22 14:22:46 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHEA-2016:0285 0 normal SHIPPED_LIVE nodejs010 bug fix and enhancement update 2016-02-22 19:03:02 UTC

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@0.0.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@0.0.6 /usr/lib/node_modules/block-stream
└── inherits@1.0.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@0.0.7
npm ERR! missing: inherits@*, required by fstream@0.1.24
npm ERR! missing: inherits@*, required by fstream-ignore@0.0.7
npm ERR! missing: inherits@*, required by fstream-npm@0.1.5
npm ERR! missing: inherits@*, required by glob@3.2.6
npm ERR! invalid: inherits@2.0.0 /usr/lib/node_modules/inherits@2
npm ERR! missing: inherits@*, required by npmconf@0.1.2
npm ERR! missing: inherits@*, required by tar@0.1.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


Note You need to log in before you can comment on or make changes to this bug.