Be nicer to the user when there was a typo #4324

Closed
binarykitchen opened this Issue Dec 16, 2013 · 2 comments

3 participants

@binarykitchen

Just typed a wrong command (typo):

$ npm cache clan

and booom, I see a big fat bold red error, a stack trace, a link to github and a log file has been generated:

npm ERR! Error: Invalid cache action: clan
npm ERR!     at EventEmitter.cache (/opt/node-0.10.21/lib/node_modules/npm/lib/cache.js:123:24)
npm ERR!     at Object.commandCache.(anonymous function) (/opt/node-0.10.21/lib/node_modules/npm/lib/npm.js:194:11)
npm ERR!     at EventEmitter.<anonymous> (/opt/node-0.10.21/lib/node_modules/npm/bin/npm-cli.js:83:28)
npm ERR!     at process._tickCallback (node.js:415:13)
npm ERR! If you need help, you may report this *entire* log,
npm ERR! including the npm and node versions, at:
npm ERR!     <http://github.com/isaacs/npm/issues>

npm ERR! System Linux 3.11.0-14-generic
npm ERR! command "node" "/opt/node/bin/npm" "cache" "clan"
npm ERR! cwd /home/michael.heuberger/projects/binarykitchen/code/xxx
npm ERR! node -v v0.10.21
npm ERR! npm -v 1.3.17
npm ERR! 
npm ERR! Additional logging details can be found in:
npm ERR!     /home/michael.heuberger/projects/binarykitchen/code/xxx/npm-debug.log
npm ERR! not ok code 0

IMO this is too much. If there was a typo, don't do that. Be user friendlier and say something like Did you mean npm cache clean?

I think this is doable by comparing the invalid command with valid ones for similarity.

Just an idea to help you guys - npm is awesome!

@othiym23

The amount of work that this would require might surprise you!

Boiled down to its essence, the problem you’re trying to solve here is enabling the CLI to distinguish between user errors and faults deeper within npm itself (either in the CLI or in the registry). For internal faults, that stack trace is very useful – for user error, not so much.

Because each subcommand has its own argument-parsing logic, making this work consistently for both top-level commands and subcommands requires touching all of the subcommands that do their own argument-handling. This is something we very much want to happen! @watilde has done a piece of this in #10382, but it only applies to top-level commands, which makes it incomplete (and the reason it hasn’t been merged yet is because in its incomplete state I’m not sure whether it’s more useful or confusing).

We intend to tackle the CLI’s UX as a whole, but this is a project that the CLI team isn’t going to have time to address within the next 6-12 months. As such, we’re tagging this as patch-welcome (because this is a thing that would be great to have) but closing it (because we won’t have time to do it ourselves. If anyone comes across this and wants to work on it, we’re happy to answer questions about what it ought to look like before it’ll be ready to merge, so please ask. Thanks for your time!

@othiym23 othiym23 closed this Jun 3, 2016
@binarykitchen

totally understand and can imagine it's it a lot more complicated than it looks like - respect

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment