You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When a prompt is aborted, the confirm message will read "[mesage] ... yes" which is slightly confusing since the value for that prompt will be "empty" (undefined).
To Reproduce
Steps to reproduce the behavior:
Prompt:
const{ requestConfirmed }=awaitprompts({type: "confirm",name: "requestConfirmed",message: `Really`,initial: true,});if(requestConfirmed){// never reached upon abort}
Start script
Abort with CTRL+C
Expected behavior
Either it displays the "no message" since that's closer to how JS would behave for implicit type conversions (Boolean(undefined) === false) or add an option to define the message for aborted confirm dialogs.
System
OS: MacOS 12.6
Terminal: ZSH
Node version: 14.18.2
Additional context
Add any other context about the problem here.
The text was updated successfully, but these errors were encountered:
For those without initial values, nothing is printed.
{
type: 'number',
name: 'age',
message: 'How old are you?',
}
...
✖ How old are you? …
In the provided example for a confirm prompt, the initial value is set to true so "yes" is printed. If the initial value is false, then "no" is printed. Since the default initial value is false if one is not provided, then you still get "no" if you don't specify.
This behavior seems unintuitive. I would be in favor of always printing no value on abort for all prompt types like in the number example above. I would happy to submit a PR.
Describe the bug
When a prompt is aborted, the confirm message will read "[mesage] ... yes" which is slightly confusing since the value for that prompt will be "empty" (
undefined
).To Reproduce
Steps to reproduce the behavior:
Prompt:
Expected behavior
Either it displays the "no message" since that's closer to how JS would behave for implicit type conversions (
Boolean(undefined) === false
) or add an option to define the message for aborted confirm dialogs.System
Additional context
Add any other context about the problem here.
The text was updated successfully, but these errors were encountered: