docs: clarify short options hopefully coming #48
Conversation
| @@ -195,8 +195,7 @@ const { flags, values, positionals } = parseArgs(argv, options); | |||
| - Does the API specify whether a `--` was present/relevant? | |||
| - no | |||
| - Is `-foo` the same as `--foo`? | |||
| - yes <-- ! kind of a blocker for shortopts ! | |||
| - Recommend: "No, -foo is shortopts form of --f --o --o" (assuming none are defined, or withValues) | |||
| - no, `-foo` is a short option or options (WIP: https://github.com/pkgjs/parseargs/issues/2) | |||
There was a problem hiding this comment.
iow, -foo must be either -f -o -o or -f oo?
There was a problem hiding this comment.
oof, that sounds like a horrific result, because how would i know at a glance what it means if that were a possibility?
There was a problem hiding this comment.
This is not a common or encouraged usage. But it is a possibility.
In this scenario the person who wrote the command invocation knows that -o takes a value. They know that you may put the value directly after the short option. They know that you may combine short options. (And if they did this in a script then apparently they don't care about the readability and maintainability!)
It might look more reasonable with a progression, and one feature at a time:
start --verbose --port 80
start -v -p 80
start -v -p80
start -vp80
Real world example:
% tar -xff
tar: Error opening archive: Failed to open 'f'
There was a problem hiding this comment.
That combination of obscure knowledge doesn't seem worth it to me to be able to do -xff instead of being forced to add a space and a dash (-x -ff).
There was a problem hiding this comment.
How is -f o -o any different than -f -o o? The order shouldn't matter for this scenario, only if f or o, respectively, is declared withValue.
There was a problem hiding this comment.
Perhaps we should make the example is -bar the same as --bar, so there isn't confusion due to the oo.
I think in both cases it should be: -b -a -r, and -f -o -o, and the multiple os would just clobber each other.
We could eventually consider adding support for multiples so that -o, -o would be o: 2, but I think this also supports the -f, -o, -o, interpretation.
There was a problem hiding this comment.
Less issues with --bar but the key point is the answer is now "no". That is a step forward for the README!
There was a problem hiding this comment.
@bcoe i'm 100% fine with what you think it should be in that comment. I found "-bar could be -b a -r or -b -a r, no matter how they're configured, both to be unacceptable.
There was a problem hiding this comment.
I'll do some fresh exploration on potential -bar equivalence to -b -a r. I went deep on this a couple of years ago because of bugs reported against Commander which at the time did a blind expansion of -foo to-f -o -o, and separately requests and PR for support for -p80. So I have been here before.
|
Thanks reviewers. I will merge this weekend if nothing else comes up. |
We do not want
-footo be the same as--foo. That much is fairly certain.-foois likely to be the same as-f -o -o, at least when plain flags. But nothing implemented yet, so point to issue rather than speculate.See #2