terkelg/prompts

Confirm dialog appends yes message when aborted

eps1lon opened this issue · 2 comments

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:

const { requestConfirmed } = await prompts({
        type: "confirm",
        name: "requestConfirmed",
        message: `Really`,
        initial: true,
      });

if (requestConfirmed) {
  // never reached upon abort
}
  1. Start script
  2. 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.

I think there's a broader discussion to be had here. What should be displayed on abort? Here's what's happening today:

For prompts with an initial value, that value is printed.

{
  type: 'text',
  name: 'twitter',
  message: `What's your twitter handle?`,
  initial: `terkelg`,
}
...
✖ What's your twitter handle? … terkelg
{
  type: 'password',
  name: 'secret',
  message: 'Tell me a secret',
  initial: 'INITIAL'
}
...
✖ Tell me a secret … *******
{
  type: 'select',
  name: 'actor',
  message: 'Pick your favorite actor',
  initial: 0,
  choices: [
    { title: 'Cage' },
    { title: 'Gyllenhaal' },
  ],
}
...
✖ Pick your favorite actor › Cage

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.

@terkelg

I agree @joeykilpatrick. Thank you