Are 'wildcard' options supported?

[rgrannell1]

Is it currently possible to use 'wildcard' options in neodoc?

I'd like to write a CLI for an application with a JSON configuration file that allows me to override any
property in the configuration file through command-line arguments. There will be dozens of properties in the file, so I'd rather not add a separate option in the documentation for each configuration property.

{
    config: {
        foo: 1,
        bar: {
            baz: 2
        }
    }
}

foo --config.foo 3
foo --config.foo.baz 3

{
    '--config.foo':     3,
    '--config.foo.baz': 3
}

I know this is possible by dynamically writing the newdoc documentation, but is there a tidier way of implementing this behaviour?.

[felixSchl]

It's currently not possible. You could, potentially, modify the JS output from neodoc.parse. Groups are represented as a list of branches and branches are represented as a list of arguments, so you could add them in there, even dynamically. Options have a trivial representation in JS. That was - in part - plan of having the intermediate step (but more prominently: performance). But since there are virtually no tests covering this and the JS output is rather rough (loses information such as [options] (already inlined), does not de-dupe #56, #60...) it might be a bit risky but could serve as an intermediate step until we add proper support for this in neodoc. I think the relevant issues that track similar work are:

• Read options from config file #53 Read options from config file — to some degree
• Add support for ranges -[0-9] #51 Add support for ranges -[0-9]
• Add a mode that collects unknown options #42 Add a mode that collects unknown options — maybe

I think we should find an implementation that works dynamically post spec parsing, because parsing the spec is too slow for bigger CLIs to ship with. I am personally interested in having some sort of wildcard mechanism as you suggested, coupled with a simple expansion mechanism (-[0-3] -> -0123) to achieve these sort of dynamic CLIs. We can occupy the star character in trailing position to mean anything past here, what do you think?

[felixSchl]

Another option you have is to use the repeating option-argument feature introduced in v0.7.0.

usage: prog [-s <key=val>...]
options:
  -s, --set <key=val>  Apply a setting.

Then $ prog -s foo=bar qux=fox would yield {"-s": ["foo=bar", "qux=fox"], "--set": ["foo=bar", "qux=fox"]}.

[felixSchl]

@rgrannell1, just a heads up I am currently implementing #75 which means you can dynamically change the spec and descriptions which should solve your use-case (provided that the set of options is known.)