Implement allowNegateOption.

[mshima]

Pull Request

Fixes #1343

Problem

• We are currently using commander with unknown option parsing using meow that allows --no- automatically.
• We implement ~25 sub commands each providing their options.
• Almost every option contains 3 states: false, true and default (saved value).
• Adding a negate option to every option is not an option:
  • help will be too big
  • not every option is added the same way, some are generated, some has to be coded.

Solution

• Add allowNegateOption() to Options.
• Add implicitNegateOptions() to Command that will set allowNegateOption() at Options.
• Fallback parsing --no-foo to --foo with false value if no --no-foo option was found.

ChangeLog

[shadowspawn]

Some initial comments. I am not sure about this.

An implicit negate for a single option is interesting, but overlaps with the current implementation. The original implementation assumed there would be just one of positive or negative option, but #795 added the ability to have both work together.

Turning on implicit negate options for a whole command is quite intrusive. Every option will have to cope with the option value potentially being false.

The implicit negate should probably appear in the help description.

[mshima]

Took your addOption from #1331.

[shadowspawn]

Somewhat related issues:

• Triage: Problems with negating boolean options #939 Triage: Problems with negating boolean options
• fixes behavior of --no-* options #795 fixes behavior of --no-* options

[shadowspawn]

There are two separate ideas in the description and original code for this PR:

• adding automatic support for --no
• having single option support for --no (rather than adding a separate --no option)

Both are interesting, but I would like more interest and use cases from the community before adding either. At the moment the use case is to match a specific existing implementation.

The single option support for --no has a disadvantage that is overlaps with the existing support, so needs to offer some compelling value to justify supporting multiple approaches.

The code changes in parseOptions in this PR are reasonably tidy. To match historical usage, the custom option processing function is only called on option-arguments and not when the option is used in a boolean way. The existing handling passes in null as the value, and tests for that in the listener. To get similar behaviour with the added --no code the listener could perhaps check for a boolean value in addition to null, or instead of null.

There are major changes to the options code coming in Commander v7 and the changes have now landed on the release/7.x branch. Have a look at what is possible and what is missing there.