[Bug] Prevent hard process exit on Ctrl+C if an onCancel callback is passed to spinner

[kajoseph]

What does this PR do?

With the spinner running, Ctrl+C hard-exits the node process with a buried process.exit(0) as noted by @43081j here. This short-circuits the spinner stop cycle which prevents the onCancel callback from running and also potentially leaves dangling connections to other services (e.g. a database).

This PR changes the behavior slightly so that an onCancel callback will prevent the cancellation cycle from calling process.exit() and instead return control back to the program so that it can cleanly teardown connections or otherwise proceed as desired. This modified behavior is more in-line with the rest of the prompts in that a Ctrl+C returns control back to the program instead of treating it as a SIGINT.

Closes #573

Type of change

• Bug fix
• Feature
• Refactor (no behavior change)
• Documentation
• Performance improvement
• Tests
• Chore (dependencies, CI, tooling)

Checklist

• pnpm test passes (or targeted tests for my change)
• pnpm format has been run
• I have added/updated tests for my changes (if applicable)
• I have added a changeset

AI-generated code disclosure

• This PR includes AI-generated code*

* only the added test cases were generated with AI as I'm not as familiar with this test harness. Suggest verifying that it's testing properly.

[pkg-pr-new]

• @example/basic

• @example/changesets

  npm i https://pkg.pr.new/@clack/core@587
  

  npm i https://pkg.pr.new/@clack/prompts@587
  

commit: 55afdd5

[43081j]

this feels like a workaround. i'll have a deeper think about it soon but i don't think we should be introducing conditional logic here. i think if we're going to do anything, we should just have an onCancel that defaults to () => process.exit(0).

but it needs some thought first

[kajoseph]

Honestly, I would prefer the process.exit call be removed entirely as it feels kind of reckless/sloppy programming-wise, but that's functionally a breaking change for users that rely on it (though I personally was relying on the spinner returning control back to the program - did this behavior change between alpha and 1.5? I digress).

I can test onCancel defaulting to () => process.exit(0). My sense is that anything more drastic would probably need to wait for a 2.0 release.