feat: allow hiding a subcommand using "-" for help

[zeroshade]

I ran into an issue where I wanted to be able to hide a subcommand from the help output (specifically for generating shell completions).

It was significantly easier to add the feature to this library (thanks for the great library!) than it would have been to switch to a much heavier CLI framework library like cobra which would require a ton more boilerplate and the inability to leverage structs and struct tags.

This PR allows specifying that a subcommand should be excluded from the help output (i.e. hidden subcommand) by explicitly adding a struct tag of help:"-" similar to how arg:"-" will exlude a field from processing.

If there's a better way to indicate this, i'm more than happy to change it. This just seemed to be simple and also consistent!

Thanks again!

[amoeba]

Hi @alexflint, I wanted to check in to see if you might have some time to look over this PR or if there's anything we can add to help with a review.

[alexflint]

Hey @zeroshade and @amoeba, thanks for submitting this, and thanks for the succinct PR - much appreciated! Wondering if you would up be for making it a "hidden" string within the "arg" tag, like this:

var args struct {
    Something *something `arg:"subcommand,hidden"`
    SomethingElse string `arg:"hidden"`
}

Rationale is that there are other ways that help text is exposed. For example, if you know of a hidden subcommand "abc" and then you write write ./cmd abc --help, then you'll still see the help for that subcommand, even though it won't be in the output of ./cmd --help.

It would also be useful to be able to hide subcommands that are for example in some kind of alpha stage, even while having written the help text that will later appear.

I realize it will make the PR a bit bigger but it would be good to apply this uniformly to both arguments and subcommands. Would require a boolean field to be added to the spec and subcommand structs to indicate hidden state. Would either of you be up for doing that?

[amoeba]

Hi @alexflint, thanks for the look. I think the new approach makes sense and will try to update this soon.

[zeroshade]

@alexflint I've updated the PR based on the approach you suggested. let me know what you think!

[alexflint]

Hey this looks absolutely great @zeroshade. Thanks so much for putting this together!

[zeroshade]

Hey @alexflint could we get a release with this included so I can point to it instead of using my own branch?

[alexflint]

Hey - just pushed v1.6.1! https://github.com/alexflint/go-arg/releases/tag/v1.6.1

[amoeba]

Thanks @alexflint, really appreciate the help here.