No error appearing if not existing command is called

[maxrimue]

I have a project using yargs and everything works as expected, except for if I call my programme with a command that doesn't exist. If I don't specify a command:

$ myapp
"Not enough arguments..."
"Use --help for further information"

If I however call my app with a command that doesn't exist, I just get no output at all:

$ myapp commandthatdoesntexist
$

The programme fails silently, not executing any of its code.
Note: All commands I specified do work as expected, also failing if not enough options are passed.

[nexdrew]

@maxrimue Thanks! I think this is the same issue as #174. There's some discussion there, but it was never implemented or resolved.

We have a few ideas for making the command API a little better which will probably be a primary feature of yargs v4, but it's been difficult to nail down a roadmap.

Have any specific thoughts or ideas on this matter? Would you expect/prefer yargs to fail-fast with a specific error message here? Would a "strict mode" for commands work for you?

[maxrimue]

Thanks for the response @nexdrew, well I think it should just say something like 'command' is not a command, and show help output based on the value of .showHelpOnFail(), so it should trigger an error with this message, which also is how my CLI programmes behave when they expect a command but receive a not existing one:

max$ brew lol
Error: Unknown command: lol

You could go even further and do it like git, which not only fails with an error output, but suggests a command based on what you typed:

max$ git vomit
git: 'vomit' is not a git command. See 'git --help'.

Did you mean this?
commit

[maxrimue]

@nexdrew Hey, I was wondering if we could start to approach version 4 by making one issue for collecting ideas for what to change, especially in the API?

[nexdrew]

@maxrimue I like that idea.

How 'bout we create a new issue ( and by "we" I mean "you" 😀 ) specifically for the next commands API that we can start throwing ideas into, and we couple that with a new 4.x label that we start throwing onto issues we think would be good candidates for yargs 4?

[maxrimue]

@nexdrew Sure, I'm on it :D

[nexdrew]

@maxrimue Awesome, thanks! I just created the label. 👍

[nexdrew]

@maxrimue If you have ideas for 4.x API changes beyond commands, just create more issues. I'm sure that (plus the new label) will help move our roadmap forward. Might want to take a look at existing enhancement issues too.

[orlade]

Handy workaround for those looking for a solution:

var commandHandlers = yargs.getCommandHandlers();
var argv = yargs
    .command('foo', 'Do the foo')
    .command('bar', 'Do the bar')
    .argv;
if (!argv._[0] || !(argv._[0] in commandHandlers)) {
  throw new Error('Must provide a valid command');
}

Works in subcommands too using argv._[1]. Note that the yargs.getCommandHandlers() method is reset after triggering yargs with .argv.

[maxrimue]

@orlade Thanks!

[OSjoerdWie]

The following call does not work (anymore):

yargs.getCommandHandlers();

The following will work:

yargs.getCommandInstance().getCommands()

Note that this function returns all command names (as well as aliases) in a string array.

My solution now becomes:

yargs
    .command('foo', 'Do the foo')
    .command('bar', 'Do the bar');
commands = yargs.getCommandInstance().getCommands();
argv = yargs.argv;
if (!argv._[0] || commands.indexOf(argv._[0]) === -1) {
	console.log("non-existing or no command specified");
	yargs.showHelp();
	process.exit(1);
}

[jazzzz]

I have the same issue with yargs 8.0.2. Is there an API to handle this or shall I still handle this myself like @orlade and @OSjoerdWie suggested?

[bcoe]

@jazzzz you should be able to use .strict() I believe, have you given this a shot? it might be worth opening a new ticket if this doesn't work, because these old closed issues tend to get lost in the shuffle.