Any way to force a help subcommand to generate?

[twilight-flower]

Consider a basic parser like this one:

use clap::{Parser, Subcommand};

#[derive(Subcommand)]
enum ExampleParserSubcommand {
	One,
	Two,
}

#[derive(Parser)]
struct ExampleParser {
	#[command(subcommand)]
	subcommand: ExampleParserSubcommand,
}

fn main() {
    ExampleParser::parse();
}

This will automatically generate a help subcommand for the root-level parser, because the root-level parser has a defined non-help subcommand. If you run cargo run -- help on this source code, this will be a valid help-menu-invocation. If you want to go out of your way to prevent that from happening, you can add #[command(disable_help_subcommand = true)] above the ExampleParser definition to prevent it; but, otherwise, no manual action is required.

However, the same doesn't apply to the subcommands themselves. If you run cargo run -- one help, it will fail with an 'unrecognized argument' error and tell you to try again with --help.

This produces an awkward-and-inconsistent interface! It means that you can sometimes open the help menu via subcommand, but other times only via flag, and therefore means that trying to do so via subcommand is risky and suboptimal-to-try-if-you-don't-already-know-it'll-work.

Thus, I'm wondering if there's any option I've missed to do the inverse of disable_help_subcommand: to force the help subcommand to generate even absent any other subcommands—for the one and two subcommands, in this example-case—and thus ensure that the help interface is consistent throughout the parser's subcommand-tree.

[epage]

Instead of having the user to force-enable help subcommands in child commands, I wonder if we should propagate down that a help subcommand should exist. Feel free to create an issue. Before moving forward, we'll need to decide (1) if yes, this is what we want and (2) if we consider this a breaking change.

[twilight-flower]

Issue created: #6227