Implied Options

[brannonh]

I just started using Commander.js yesterday, and I am very happy with it. That being said, I noticed there is no way to mark that a boolean option implies another boolean option. My thought process is that if such a boolean option is provided to the program, the implied option(s) would also be set to true.

Having this available would allow for less verification code within the program itself. You could always check a single option, rather than checking multiple options.

As an example, here's a(n edited) snippet of my current code:

program
  .option('-d, --dump', 'dump data on error and end of execution')
  .option('-t, --trace', 'log everything (implies -d)');

Currently, I would either have to check for both options or check for -t and set -d. With an implied option, I could do something like this (rough example):

program
  .option('-d, --dump', 'dump data on error and end of execution')
  .option('-t, --trace', 'log everything')
  .implies('trace', 'dump');

The automated help would also automatically add something like (implies -d) to the description for the trace option.

I would think that a negatable boolean option would take precedence over the implication (i.e., program -t --no-dump would result in trace being true and dump being false).

Anyways, that's all. I think this would be a nice addition to Commander.js' current functionality. If it's possible now and I just missed it, please let me know. Otherwise, I'm also always open to feedback. Thanks!

[shadowspawn]

Thanks. Another other sort of configuration sometimes offered is mutually exclusive options.

I see these as fairly low value as only a few lines of code to do the exact custom logic required. Happy to leave issue open though, and see if it is popular. 👍

[brannonh]

Thanks for the feedback. I understand that completely. I guess the value would be higher in cases where the custom logic is required in multiple places. In that case adding/removing a flag implication would require updating the custom logic in all of those places, which always opens the door for missing one.

[shadowspawn]

Related: #1391 #1408 #1530

[hildjj]

Is there a good place to throw an InvalidArgumentError after parse() such that _displayError() gets called? If I'm checking further semantics of interrelated options and arguments, I'd like the formatting and exitOverride behavior to match what parse() does.

I suppose I could call _displayError() myself and rely on it throwing in the exitOverride case, but I hate to rely on an obviously-intended-private member function.

[shadowspawn]

Is there a good place to throw an InvalidArgumentError after parse() such that _displayError() gets called?

Um (double-checks in code)... no. The InvalidArgumentError handling is written for exceptions from the custom processing for an option or a command-argument, not from other locations.

If you would like to explore this further, please open a separate issue. I support your desire to not use private member functions!

[shadowspawn]

For potential interest to people following this issue, there is a PR open for similar-but-different conflicts. See #1678

[shadowspawn]

I am experimenting with calling signature Option.implies(optionBag) that specifies the implied options and their values, like:

program
  .addOption(new Option('--quiet').implies({ logLevel: 'off' }))
  .addOption(new Option('--log-level <level>').choices(['info', 'warning', 'error', 'off']).default('info'));

[shadowspawn]

Commander v9.3.0 adds Options.implies()