Closed aaronccasanova closed 1 year ago
@aaronccasanova I actually prefer this implementation over mine, seems simpler. Just need Sindre's approval though I think they are quite busy with other projects :D
Great solution. Using this and it works perfect.
It does break redent
(because it's looking at options.help
instead of however deeply nested .help
could be, so I'm just wrapping my nested help
s in redent('my help text', 2)
to fix it for now.
Sorry for the late reply. I also think this is the way to go.
@aaronccasanova Do you want help with getting this draft merged? I'm willing to help to speed up the merging process :)
Do you want help with getting this draft merged?
Hey @skoshx! Yes! My bandwidth is limited at the moment and I would greatly appreciate help getting this PR out of draft 🙌
Here are some outstanding todo items:
allowParentFlags
to restrict top level options.flags
from being used with a given subcommand. Do we want this functionality? Should it be more flexible? Is it out of scope for v1 of subcommands?handler
callback to each subcommand options. While it doesn't factor into the implementation, I'm curious if there is a preference to encourage or discourage users adding arbitrary properties to the meow
options?cli.command
object with the following shape:// node barista.js brew tea
cli.command === {
// Array of each subcommand passed to the CLI
args: ['brew', 'tea'],
options: {/* tea subcommand options */}
}
Closing to avoid leaving stale PRs in this repository
@aaronccasanova I'd like to help get this merged. Some thoughts from trying to use this:
cli.input
includes any parsed cli.command.args
. I think cli.input
should be amended to be all non-flag and non-command argumentscommand.args
? The parsed flags, help text, etc. are merged into cli
anyway. cli.command
could just be the user-inputted commands.
cli.command === 'brew tea'
)cli.command
should be omitted from the result?You'll notice in my example I'm passing a handler callback to each subcommand options.
I don't think this kind of usage should be encouraged.
I tentatively included an allowParentFlags to restrict top level options.flags from being used with a given subcommand. Do we want this functionality?
I think this could be useful. Imagine if the top-level CLI defines a --verbose
flag. Subcommands shouldn't have to redeclare that flag just to get access to it. There are some potential issues though:
cli.help
becomes the subcommand's help
text, what happens to top-level options? Are users required to copy their usage information for a given flag to each subcommand?I'd be happy to help, especially with types/documentation. I can also take a look at the redent
issue.
I've been experimenting with an alternative approach to PR# 205 for adding
subcommands
support. My favorite feature ofmeow
is the objects as configuration convention forflags
and I was interested in exploring how to carry over that pattern forsubcommands
. I'm pretty satisfied with the POC and would love some initial feedback before I continue iterating and moving this PR out of draft.Key features:
subcommands
subcommands
subcommands
use the existingmeow.options
properties to keep the API minimal, extensible, and familiar--help
(withautoHelp: true
) automatically shows the help text for the currentsubcommand
allowParentFlags
option is introduced to restrict top leveloptions.flags
from being used with a givensubcommand
cli.command
) containing the inputargs
of thesubcommand
and a reference to the resolvedsubcommand
s optionsHere is a subset of the proposed API! Though, I recommend pulling down the branch and testing out
barista.js
with the provided examples.