feat: Allow multiple options to be passed to `addOption`

[ieedan]

I currently have a lot of options shared between different commands and instead of redefining the same options on each command I instead have resorted to using a commonOptions object with the options that I use frequently. This works good for me but at the moment I am forced to do:

new Command("add").addOption(commonOptions.cwd).addOption(commonOptions.all)

It would be a lot more ergonomic if I could do something like:

new Command("add").addOption(commonOptions.cwd, commonOptions.all)

I currently have this pnpm patched to just add an addOptions method but it may be better to just add a spread array onto addOption to allow this without introducing new apis.

Let me know what you think and I can open up a PR!

[shadowspawn]

It is fairly easy to loop over the "commonOptions", but I appreciate that does not fit into the chaining pattern and requires a local variable for the subcommand.

Looking at wider usage, there is also addArgument() and addCommand(). addCommand() takes an extra parameter which breaks the simple pattern and does not extend to variadic.

I'm interesting in seeing if this gets many likes.

[ForkKILLET]

Or addOptions?

[ieedan]

Or addOptions?

This is how I had it patched in my project also good with this

[jdmarshall]

I suppose the alternative is

    [commonOptions.cwd, commonOptions.all].map(() => command.addOption());

But does that chain properly? Probably actually need reduce

[jdmarshall]

But I think as someone who works on CLIs that coworkers also work on, I'd rather see:

    .addOption("-f --file ..."),
    .addOption(commonOptions.verbose)
    .addOption(commonOptions.all)

It gets a little weird when you have five commands in a single file, but none of the options I see above make that any less awkward. The only thing that might is

Command.addOption(commonOptions.all);

new Command("add")
    .addOption("-f --file ...")