Show hidden options

[laggingreflex]

In #962 a new option was added {hidden: true} that hides an option from --help (instead of by omitting the description)

To show these hidden options, one of the suggestion was to use --yargs-show-hidden (@gajus).

How about instead, modify the showHelp like this:

yargs.showHelp('log', {showHidden: [true|false]})

This gives the user more control. Like maybe they wouldn't want to show hidden commands at all. Or maybe they'd want it behind a custom flag. This way they can implement it themselves.

It however require that the user implements the --help themselves too:

const argv = yargs
  .options({
    baz: {
      describe: 'BAZ',
      hidden: true
    },
    'show-hidden': {
      describe: 'Show hidden options',
      type: 'boolean'
    },
  })
  .help(false)
  .argv

if (yargs.help) {
  yargs.showHelp('log', {hidden: argv.showHidden})
}

[bcoe]

@laggingreflex I feel like it would potentially limit the number of folks who find this feature, by forcing a user to handle the help output themselves -- it also means that features like validation are a bit less interesting; I'm not the biggest fan of adding --yargs-show-hidden either, as I think it exposes a bit too much of yargs' internals.

I'm heads down trying to get a few more things patched for yargs@10.x; but let's sit on this for a bit and figure out something soon.

[bcoe]

@laggingreflex coming back to this issue after putting it down for a bit; I think that the suggestion of:

yargs.showHelp('log', {showHidden: [true|false]})

is pretty reasonable -- any interest in rebasing with this functionality?

[gajus]

is pretty reasonable -- any interest in rebasing with this functionality?

I don't think it is optimal.

It requires code change to change CLI behaviour.

Users will opt-in to use an arbitrary environment variable to control this feature instead, e.g.

yargs.showHelp('log', {showHidden: process.env.MY_SHOW_HIDDEN})

Hidden options is yargs feature and as such yargs should provide a standardised way to control the behaviour instead of "outsourcing" the decision to the consumers.

[bcoe]

@gajus I dislike that having a command line argument like --yargs-show-hidden is a leaky abstraction. People consuming foo-library shouldn't need to know that it's yargs behind the scenes.

Perhaps there's an argument --show-hidden, which only takes effect if --help has also been called? That seems like it would be unlikely to collide with other CLI applications.

[gajus]

@gajus I dislike that having a command line argument like --yargs-show-hidden is a leaky abstraction. People consuming foo-library shouldn't need to know that it's yargs behind the scenes.

You could argue the same about --help.

Are you specifically opposing yargs name appearing?

--show-hidden or --show-hidden-options sounds generic enough that it will unlikely to clash.

[bcoe]

@gajus I'm specifically objecting to the --yargs prefix; I think a --show-hidden flag would be a good approach.

@laggingreflex, @gajus would either of you like to see this over the finish line? Otherwise I hopefully will carve some time for open source out over the holiday.

[laggingreflex]

Superseded by #1061