fix: correctly specify return type of CANCEL_SYMBOL

[gameroman]

What does this PR do?

Closes #600

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

[changeset-bot]

🦋 Changeset detected

Latest commit: 8ae1524

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 2 packages

Name	Type
@clack/core	Patch
@clack/prompts	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[pkg-pr-new]

• @example/basic

• @example/changesets

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

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

commit: 8ae1524

[trueberryless]

Could you add a changeset with a patch bump, pls?

[dreyfus92]

this looks good! but, could we add a type-level regression test? something like

if (isCancel(value)) return;
expectTypeOf(value).toEqualTypeOf<string>();

inside an existing text or path test. tsc passed on the 1.8.0 base, so nothing today would fail if the narrowing drifts again. expectTypeOf is already available from vitest and the test dirs are typechecked in CI.

cc @43081j

[43081j]

we do already type check via tsc if i remember correctly. so i think instead of having vitest redo this, just write a regular unit test that uses isCancel narrowing and the compiler will catch it instead of vitest.

otherwise vitest has to run typescript again internally

e.g.

if (isCancel(result)) {
  expect(result).toBe(CANCEL_SYMBOL);
} else {
  expect.fail();
}

something like this

[dreyfus92]

so we're aligned on this one. @gameroman please add a regular unit test to verify there isn't a regression with this one 👀

[gameroman]

we do already type check via tsc if i remember correctly. so i think instead of having vitest redo this, just write a regular unit test that uses isCancel narrowing and the compiler will catch it instead of vitest.

What Paul suggested will also only checked once when we run by tsc, vitest will ignore it if you don't do vitest --typecheck

expectTypeOf(value).toEqualTypeOf<string>()

[43081j]

Typescript won't check those assertions, vitest does in type check mode. So it's dead code in a regular type check.

Vitest type assertions are only useful if you don't already run tsc yourself

[gameroman]

Typescript won't check those assertions

It does

https://github.com/gameroman/clack/actions/runs/34639636806/job/103395892421?pr=1