Adding CommandOptions to branch requires options to be defined BEFORE subcommands

Information

• OS: Windows
• Version: Commit: e4dda28
• Windows terminal

Describe the bug Adding CommandOptions to branch requires options to be defined BEFORE subcommands

To Reproduce Use Demo project and extend AddSettings with this:

        [CommandOption("--quiet")]
        [Description("Quite mode")]
        public bool Quiet { get; set; }

> Demo.exe add wo package pkt --quiet
┌──────────────────┬───────┐
│ Name             │ Value │
├──────────────────┼───────┤
│ PackageName      │ pkt   │
│ Version          │ null  │
│ Framework        │ null  │
│ NoRestore        │ False │
│ Source           │ null  │
│ PackageDirectory │ null  │
│ Interactive      │ False │
│ Project          │ wo    │
│ Quiet            │ False │
└──────────────────┴───────┘

Quit is here FALSE even though I clearly gave it as an option to the command.

Demo.exe add wo --quiet package pkt
┌──────────────────┬───────┐
│ Name             │ Value │
├──────────────────┼───────┤
│ PackageName      │ pkt   │
│ Version          │ null  │
│ Framework        │ null  │
│ NoRestore        │ False │
│ Source           │ null  │
│ PackageDirectory │ null  │
│ Interactive      │ False │
│ Project          │ wo    │
│ Quiet            │ True  │
└──────────────────┴───────┘

Gives Quite = true

Expected behavior I expected CommandOption:s can be assigned anywhere on the commandline. I´ve never seen CLI:s requiring this strict order.

With CommandArguments it’s might be more intuitive to assign arguments to each command in order: “X arg1 arg2 Y arg1 arg2”. But this cant be the case with options. Examples of usages would be great on the https://spectreconsole.net/cli/composing page

[patriksvensson]

@Goffen Thanks for reporting this. Will take a look at it closer when I have some spare time.

[Simonl9l]

@PsychoNineSix Id suggest that it is also valuable to want to place the settings on the branch, and expect the Argument to show as you had originally expected (per --help options) as the argument applies to all subcommands - so I’d say un-scratch!

I assume it is “not normal” to have branch options separated from their sub command options as today all the options are moved to the end regardless of what part of the setting call hierarchy they are in - this implies that there are multiple sets of options, those as part of the branch and this and part of the selected sub command one is looking at --help for?