-
Notifications
You must be signed in to change notification settings - Fork 10
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat!: switch type:string option arguments to greedy, but with error for suspect cases in strict mode #88
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see this is still in draft but looks good so far 👍
I wanted to take a serious look at how we handle I think it is a coin-flip for greedy vs choosy, in trade-offs and implementations, and the feedback was split. Because we default to I think this PR is a good compromise of POSIX compatible behaviour when (Full disclosure, we could still do the fancy error message if we stuck with choosy mode!) |
This comment was marked as outdated.
This comment was marked as outdated.
Bumping this for consideration in case being ignored because I never put it forward for MVP. I proposed this behaviour in (#77 (comment)) for feedback before pushing it for MVP, and then the node PR got opened and things got busy. :-) Feedback was 3 x 👍 (including me). |
I think this is probably the best behavior, though any of the possibilities seem OK. +1 from me.
I think const arg = /^[a-zA-Z0-9\-_]+$/.test(value) ? value : `'${value.replace(/[\\']/g, '\\$&')}'`; will omit quotes in cases where they're obviously unnecessary and include them in the remaining cases. |
@shadowspawn do we want to land this for MVP? |
I would like to. It would be a breaking change in future as changes the parsing behaviour in But it isn't essential. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One recommendation, let me know what you think?
if (strict && isOptionLikeValue(optionValue)) { | ||
// Only show short example if user used short option. | ||
const example = (shortOrLong.length === 2) ? | ||
`'--${longOption}=-XYZ' or '${shortOrLong}-XYZ'` : |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
rather than -XYZ
, any reason not to make this --${longOption}=${optionValue}
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Short version: Quoting.
I actually had that but then worried about quoting it correctly in all cases, on all platforms, so it would work if copied and pasted. Went for a short safe placeholder!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(I'll have a look for a future PR at using the value in the error message if it is plain text.)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, I will merge this tomorrow before I rebase the upstream pull request in Node.js.
Moved high-level greedy tests into |
Should we make options expecting arguments greedy or choosy?
See #79 for survey of behaviours.
How about greedy, but with explanatory error for arguments which start with a dash when in strict mode?!
See #77 (comment)
Closes #77
Greedy is consistent with POSIX and Commander when
strict:false
and simple to describe. In strict mode we throw an error due to the possible mistake by end user omitting argument with an explanation of how to proceed if not a mistake.These arguments will be eaten in
strict:false
and throw a helpful error instrict:true
.--foo --
--foo -a
--foo -2
--foo --bar
Errors:
Notes:
--foo "--bar alpha *test"