Discussion: do we need `laxPlacement`?

[felixSchl]

I am re-working the argparser again, still not being a 100% satisfied with the current behavior. This time I've decided to completely neglect the idea of laxPlacement and instead use it as the default behavior, meaning options can appear anywhere in the input, while still respecting "options-first" parsing, "--" and unknown option parsing. Among 1400 odd tests only a single test would fail due to this behavior, making me wonder the validity of bothering to even keep the old behavior. I saw value - originally - to be able to add options in particular regions of the command line to - in a way - configure subcommands, but in reality there's only a single [options] tag (until #57 comes to fruition - if ever) and composition of larger command lines probably means that each subcommand would want it's own help (like the git example).

Hence I am compelled to abandon the idea and rely on downstream users composing their programs accordingly to achieve a similar effect (using the "options-first" feature).

NB: These changes will go into version 2 of neodoc so I am happy to break backwards compatibility here to a level.

[fidian]

I've exclusively used laxPlacement: true in all of my projects. Usually, I define my command like this:

some-command [options] <categoryId> <action>

I always want the option --config file.json to appear in any place.

./some-command --config file.json jewelry show
./some-command jewelry --config file.json show  # weird, but ok
./some-command jewelry show --config file.json