Having a lot of difficulty getting nested commands

[ProLoser]

So my coworker and I have been trying to use this library and we keep on running into problems.

I want to have 2 sub-commands. I want 1 command to execute by default if no command is specified. Both commands take Variadic arguments. I'd like to have top-level options that are used by sub commands, as well as sub-command specific options.

The results are constantly confusing (I don't get why not having a 'description' argument vs calling .description() has such a significant impact on behavior for example). It wasn't explicitly stated anywhere in your docs that calling .action() or .command() in any particular order was significant, or if calling .option() in between those calls are significant, or if options cascade (although in several examples they appear to), or if / when I'm supposed to put an [options] into my command or usage? Do I even need .usage()?

Doing things like node index.js --help vs node index.js action --help will almost never BOTH work (I seem to be able to get one or the other to work).

I've seen errors where a top-level option is missing, and then when I specify it, I get an error saying that the very same option doesn't exist.

It's mind numbing. My experience using this library has been tweak the options a little and try running the script and seeing how commander vomits, rinse and repeat until you figure out the general gist of what you're supposed to do.

[privateOmega]

@ProLoser Have you ever figured out why the problem occurs? I too am at the same point.

[ProLoser]

I think I went with a simpler library and did more heavy lifting myself but I don't remember the project.

[mojavelinux]

I don't get why not having a 'description' argument vs calling .description() has such a significant impact on behavior for example

Based on my understanding of this library, if you pass a description to the command() call, that creates an executable-based command. If you instead set the description using a description() call, that creates an action (i.e., callback-based) command. These two types of commands are processed differently. While they should have generally follow the same rules, due to inconsistencies / bugs in the code, they sometimes differ.

I agree it would be nice if the documentation better explained the difference between the two types of commands and the implications of choosing one versus the other. I don't think "Git-style sub-commands" is the most appropriate heading.

[shadowspawn]

Good comment that "Git-style sub-commands" is not the most appropriate header.

There are multiple other issues open about confusion over description changing behaviour, and I have this issue noted to link later.

This issue has not had any activity in over six months. It isn't likely to get acted on due to this report.

Feel free to open a new issue if it comes up again, with new information and renewed interest.

Thank you for your contributions.