bun-test-cli-harness

bun:test compatible harness for testing Inquirer & Ink based CLIs. Vendors @inquirer/testing's Screen API and ships a bun.ts entry that mocks every @inquirer/* prompt package via mock.module, so sand-style prompts can be driven programmatically without a PTY.

Install

bun add -d bun-test-cli-harness

Usage

Import the harness once at the top of your test file (before any module that uses @inquirer/prompts) so the mocks register before the CLI under test loads its prompt imports:

import 'bun-test-cli-harness'
import { screen } from 'bun-test-cli-harness'
import { test, expect } from 'bun:test'
import { createCommand } from '../src/commands/create.ts'

test('create-sandstone library flow', async () => {
  const result = createCommand('/abs/path/to/project', { root: false })

  // Each prompt renders synchronously; send input then wait for the
  // transition with `screen.next()`.

  // confirm: library?
  screen.type('y')
  screen.keypress('enter')
  await screen.next()

  // version: default
  screen.keypress('enter')
  await screen.next()

  // …drive remaining prompts the same way.

  await result
}, 180_000)

screen API:

• screen.type(text) — writes characters to the prompt's stdin and emits keypresses for each one.
• screen.keypress(key) — emits a single named keypress (e.g. 'enter', 'down', 'up').
• screen.getScreen() — current prompt text (ANSI stripped).
• screen.next() — resolves when the next render happens (re-render of the current prompt or the next prompt's first render). The very first prompt's render is available synchronously via getScreen() without next().
• screen.clear() — automatically called between tests via beforeEach.

Why

bun:test doesn't speak jest.mock, so @inquirer/testing/jest's module mocking doesn't work directly. This package wraps mock.module with the same "mock every @inquirer/* prompt" coverage, so you get the upstream API without writing the boilerplate.

License

MIT — see LICENSE.