Make `variadic` optional for array types
akuntsch opened this issue · 3 comments
Is your feature request related to a problem? Please describe.
No
Describe the solution you'd like
The variadic property for array flags should be optional, so that one can return the correct array type in the parse method, e.g. by splitting an input string on a certain character.
Maybe even make it possible to return an array from parse with variadic: true and then flatten all of the returned arrays.
Describe alternatives you've considered
There are none that I know of.
Additional context
I want to migrate our internal CLI to stricli and while we could just use the current variadic implementation, we have certain use cases where repeating the flag name 10 times is much more to type and also less readable than just passing a single comma-separated string to the flag and then splitting it.
Ah so rather than --flag one --flag two returning flag: ["one", "two"] you would want to have the option for --flag one,two instead. That seems like a reasonable change to me, and should be easy enough to control by the variadic property.
Yes, that would be one use case.
The second use case I meant would be --flag one --flag two,three returning flag: ["one", "two", "three"], although that's a bit more exotic (and maybe not so reasonable).
Also the delimiter should probably be configurable, which would be the case, if the splitting had to be done in parse().
Yeah being unable to use --flag one,two seems more like an issue with the existing type logic as it forces variadic whenever the target type extends an array. There should be no reason to prevent the parsing logic from accepting a string "one,two" and returning an array.
However, I don't think it would make sense to support the --flag one --flag two,three use case (at least right now) as non-variadic parsed flags only accept a single value with no way of combining multiple inputs. I'm not opposed to it, but it needs some prototyping to make sure it's not clunky/confusing to use.