Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP

Loading…

output all errors at end when using "npm ls" #3030

Closed
defunctzombie opened this Issue · 3 comments

2 participants

@defunctzombie

The following script helps reproduce the usability issue:

#!/bin/bash

tee package.json <<EOF
{
    "name": "foo",
    "version": "0.0.0",
    "dependencies": {
        "mkdirp": "0.3.4",
        "mocha": "1.7.4"
    }
}
EOF

npm install
rm -rf node_modules/mocha/node_modules/mkdirp
npm ls

If you create a dir and run the above you will see output similar to the following:

npm WARN package.json foo@0.0.0 No README.md file found!
npm WARN unmet dependency /Users/shtylman/tmp/repro/node_modules/mocha requires mkdirp@'0.3.3' but will load
npm WARN unmet dependency /Users/shtylman/tmp/repro/node_modules/mkdirp,
npm WARN unmet dependency which is version 0.3.4
foo@0.0.0 /Users/shtylman/tmp/repro
├── mkdirp@0.3.4 invalid
└─┬ mocha@1.7.4
  ├── commander@0.6.1
  ├── debug@0.7.0
  ├── diff@1.0.2
  ├── growl@1.6.1
  ├─┬ jade@0.26.3
  │ └── mkdirp@0.3.0
  └── ms@0.3.0

npm ERR! invalid: mkdirp@0.3.4 /Users/shtylman/tmp/repro/node_modules/mkdirp
npm ERR! not ok code 0

While the first few lines are very clear about what the issue is, the last line is quite misleading. Package mkdirp 0.3.4 is valid but just happens to be incorrect for mocha 1.7.4.

This would be less confusing if all the warning lines above the list were actually below it. Those warnings are also the real error in this case and not just the fact that mkdirp is "invalid" (which by itself is very vague as well).

I would suggest:

  • make all warning and errors appear at the end of the npm ls output (where the user is more likely to notice them) This is even more important when there are many modules and the user would need to scrollback to see the real issue. Saying err at the end makes them think that is the issue.
  • turn version mismatches into errors. It isn't just a warning, it is actually an error since the program may not run as installed
  • avoid just saying "invalid" and instead be more descriptive when possible.
@timoxley
Collaborator

@defunctzombie:

> npm ls
package-bar@0.5.0 .../package-bar
├── package-foo@0.5.0 -> .../package-foo extraneous
├── semver@1.0.0 invalid
└── semver@2.2.1 (semver~backup) invalid extraneous

npm ERR! invalid: semver@1.0.0 .../package-bar/node_modules/semver
npm ERR! extraneous: semver@2.2.1 .../package-bar/node_modules/semver~backup
npm ERR! invalid: semver@2.2.1 .../package-bar/node_modules/semver~backup
npm ERR! extraneous: package-foo@0.5.0 .../package-bar/node_modules/package-foo
npm ERR! not ok code 0

make all warning and errors appear at the end of the npm ls output

appears done

turn version mismatches into errors.

appears done: npm ERR! invalid: semver@1.0.0 .../package-bar/node_modules/semver

avoid just saying "invalid" and instead be more descriptive when possible.

Maybe you could submit a PR for the change or create a new issue for this? i.e. can this be closed as the bulk of the issue seems resolved and low impact things like your final request seem unlikely to get into npm unless there's a PR ready to go.

#4430

@defunctzombie

@timoxley if you follow the above instructions it will still output unmet dependency warnings first. I guess those are warnings but those warnings help you track down the final error (invalid: mkdirp) which is printed at the end and are far more helpful than the "invalid" printed.

I am gonna go ahead and close this since there are certainly more important issues to tackle than this :)

@timoxley
Collaborator

:tada:

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.