Inquirer.js splits into @inquirer/prompts and a legacy inquirer package, and the split matters

Each prompt is a separate import from @inquirer/prompts

The current API exposes one function per prompt type, all from @inquirer/prompts: input, select, checkbox, confirm, search, password, expand, editor, number and rawlist. Each lives in its own package under packages/ with its own documentation, and you import only what you call. You can try them all in your own terminal with the demo package:

npx @inquirer/demo@latest

A prompt is an async function that resolves to the answer:

import { input } from '@inquirer/prompts';

const answer = await input({ message: 'Enter your name' });

number is the input prompt with a built-in number validation option, so you do not have to parse and reject strings yourself.

The rewrite left community prompts on the old inquirer package

Inquirer was rewritten from the ground up to reduce package size and improve performance. The previous package, inquirer, still lives in packages/inquirer and still gets releases, with [email protected] published on 27 October 2026. It is maintained but not actively developed.

The cost of the rewrite is the ecosystem. The old package had hundreds of community contributed prompts, and some of them have not been migrated to the new API. If your CLI relies on one of those, moving to @inquirer/prompts means writing that prompt yourself or staying on a package that only gets maintenance. Audit your prompt types before you migrate, not after.

A second argument controls streams, screen clearing and cancellation

Every prompt function takes two arguments. The first is the prompt configuration, which differs per prompt. The second is runtime context, shared by all of them:

input is the stdin stream and defaults to process.stdin. output is the stdout stream and defaults to process.stdout. clearPromptOnDone, when true, clears the screen after the prompt is answered. signal takes an AbortSignal so you can cancel a prompt asynchronously, for example on a timeout.

Custom streams come with a caveat. The README warns that when you provide an input stream or pipe process.stdin, you need an extra call on process.stdin to set raw mode. Skip it and a prompt fed from a pipe will not behave like one attached to a terminal.

On Deno, prompts need --allow-env to detect the terminal

The package installs from every common JavaScript package manager:

yarn add @inquirer/prompts
pnpm add @inquirer/prompts
bun add @inquirer/prompts
deno add npm:@inquirer/prompts
npm install @inquirer/prompts

Deno is the one with a runtime requirement. Prompts detect the terminal's unicode and color support from environment variables, so a Deno script has to run with --allow-env. Without that permission, the detection cannot read the environment it depends on.

The editor prompt hands the answer to $VISUAL or $EDITOR

editor works differently from the other prompts. It launches the user's preferred editor on a temporary file, and when the user exits, the file's contents become the answer. The editor comes from $VISUAL or $EDITOR. If neither is set, the OS default is used: notepad on Windows, vim on Mac or Linux.

That fallback is a real usability risk. A user on macOS or Linux with no editor variable set lands in vim, and someone who does not know how to save and quit cannot finish the prompt. If your audience is not developers, use input for short text, or document that they should set $EDITOR first.

Translations come from @inquirer/i18n with five built-in locales

Prompts are in English by default. For other languages, @inquirer/i18n is a drop-in replacement for @inquirer/prompts with the same function names. Its root import detects the locale from LANGUAGE, LC_ALL, LC_MESSAGES and LANG, falling back to the Intl API, and uses English if no supported locale matches.

The built-in locales are English, French, Spanish, Chinese (Simplified) and Portuguese. Users in any other language get English unless you add a locale yourself with createLocalizedPrompts and registerLocale. To force one language regardless of the environment, import a sub-path such as @inquirer/i18n/fr.

Custom prompts build on @inquirer/core and test with @inquirer/testing

When none of the ten prompts fits, you write your own on @inquirer/core, the API layer the built-in prompts use, and test it with @inquirer/testing. Both are packages in the same monorepo.

The repository is a Yarn workspace of packages/, integration/ and tools/, built with turbo and published with lerna-lite, so each package has its own version. On 27 October 2026, @inquirer/[email protected], @inquirer/[email protected] and [email protected] shipped together, and the last push was on 31 October 2026. Because the version numbers differ by package, pin @inquirer/prompts and any core or testing packages you use separately rather than assuming they move in step.

Editorial conclusion

Use @inquirer/prompts if you are writing a new Node.js or Deno CLI and the ten built-in prompts cover what you ask users for. Stay on the legacy inquirer package only if you depend on a community prompt that has not been ported, accepting that it is maintained but not actively developed. Before choosing, check whether every prompt type you need exists in the new API, and on Deno confirm your script runs with --allow-env.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. Releases
5. SBoudrias/Inquirer.js on GitHub