feature: add method to hide option extras

[jly36963]

Addresses: #2153

Description

Given the following:

yargs('cmd1 --help')
  .command(
    'cmd1',
    'cmd1 desc',
    yargs => yargs
      .option('opt1', {
        type: 'string',
        choices: ['foo', 'bar', 'baz'],
        alias: 'o',
        required: true,
        description: "A long description that might break formatting"
      }),
    argv => console.log(argv)
  )
  .hideOptionExtras()
  .strict()
  .parse()

The hideOptionExtras would cause the following output

cmd1 desc

Options:
      --help     Show help                                             [boolean]
      --version  Show version number                                   [boolean]
  -o, --opt1     A long description that might break formatting
                              [string] [required] [choices: "foo", "bar", "baz"]

to look like this instead

cmd1 desc

Options:
      --help     Show help
      --version  Show version number
  -o, --opt1     A long description that might break formatting

Questions

If this works, I'll add unit tests.
What other things would need to change? (docs, examples, etc)

[bcoe]

I'm worried about adding one off functions to tweak yargs' default layout. What if instead we did something like we did with parserConfiguration. Add a helper usageConfiguration, which we can gradually add more layout options to:

yargs.usageConfiguration({
  'show-types': false
})

[bcoe]

@jly36963 this is great work, thank you 👏

One ask, would it be possible to add this setting in the list here: https://github.com/yargs/yargs/blob/main/docs/api.md#parserconfigurationobj

[bcoe]

Love this. I think usageConfiguration will help us provide nuanced configuration without adding 1,000,000 additional methods.

[ljharb]

I’m a bit confused; how can i show types in general, but hide types for an a specific option?

[jly36963]

@ljharb I don't think there is a way currently. It would likely be a new property on option/positional objects like hideUsageTypes, or potentially a refactor on the usage logic to allow for customizations.

I won't be involved with this package much in the future, so I won't be much help in implementing this change

[ljharb]

In that case, this does not solve #1145, thanks for confirming.