Closed chshersh closed 1 year ago
Hi, i want to take this one as my first task. I found a breaking case that is when the custom parser defines --no-input [TARGET] while being a mandatory option. Defined like this the app always displays the help/error message "expected: ...". I assume this is the second case of the listing above. Should i still assume this as the wanted behavior? And does it make sense to add the tests before #67 as i would define custom CliEnvSettings with a custom parser?
@zetkez Feel free to give it a go! All CLI tests can be found in this module (and can be added here for now):
I believe, it makes sense to test several combinations:
--no-input
as an on-off flag--no-input=[SOME_VALUE]
as a flag that expects a valuemy-command --no-input
: when a custom command expects the same flagOnce we have these 3 test cases, we can improve the documentation to reflect this behaviour 🙂 The point of this issue is not to fix the behaviour but to discover what is the actual existing behavior and document it for our users.
Hope that helps!
Similar to #56
People shouldn't specify options that conflict with ours. But if they still do, it would be nice to know whether their parsing conflicts with ours. So I propose to add two tests and document their results in public API:
my-program --no-input
when the custom parser specifies--no-input
as well (ideally this should be checked by #13)my-program --no-input my-command --no-input
is confusing but ideally should be parsed and return different results for different--no-input
. If not, having a test is still good and documenting this behaviour is nice.