Inquirer.js: Interactive CLI Prompts for Node, Rewritten as @inquirer/prompts

The problem Inquirer.js solves for Node CLI authors

Node gives you process.stdin and process.stdout. It does not give you a menu, a multi-select with arrow keys, a password field that hides keystrokes, or a confirmation dialog. Building those on raw terminal input means handling raw mode, ANSI escape sequences, cursor movement, and platform differences yourself. Inquirer.js is a collection of those widgets, published as npm packages, so a scaffolding tool or an installer script can ask a question and get a typed answer back.

The audience is narrow and specific: authors of Node.js command line tools. Yeoman-style generators, create-* scaffolding commands, configuration wizards, and any CLI that needs to collect a few values before doing work. The repository's package.json keyword list includes scaffold, scaffolder, scaffolding, generator, yeoman and yo, which is a fair description of who the library was built for. If your program is a long-running server or a library with no terminal interaction, this is not the package you want.

How the prompt packages fit together after the rewrite

The README states that Inquirer underwent a rewrite from the ground up to reduce package size and improve performance. The visible result is a split: the modern entry point is @inquirer/prompts, and each prompt also has its own package directory in the repository, such as packages/input, packages/select, packages/checkbox, packages/confirm, packages/search, packages/password, packages/expand, packages/editor, packages/number and packages/rawlist. The root import re-exports the individual prompts, so you can either import from @inquirer/prompts or from a narrower package.

The mechanism is a promise. You call a prompt function with an options object containing at least a message, and you await the answer. The prompt takes over the terminal, renders the widget, handles keypresses, and resolves when the user submits. There is no separate render loop for you to drive and no state object to poll. The README's usage example is one import and one await:

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

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

The editor prompt is the outlier in how it works. According to the README it launches the user's preferred editor on a temporary file, reads the file contents back as the answer when the editor exits, and picks the editor from $VISUAL or $EDITOR, falling back to the OS default (notepad on Windows, vim on Mac or Linux). That is a different interaction model from the arrow-key prompts, and it depends on environment variables being set sensibly on the user's machine.

Installing @inquirer/prompts and running a first prompt

The README gives install commands for four package managers. Pick the one your project already uses, because mixing lockfiles is its own problem.

npm install @inquirer/prompts

yarn add @inquirer/prompts

pnpm add @inquirer/prompts

bun add @inquirer/prompts

Before writing any code, the README suggests trying the prompts in your own terminal with the demo package. This is the fastest way to see which widget matches the question you are asking, and it needs no project setup:

npx @inquirer/demo@latest

For a first real use, the README lists select among the prompts and shows the import line for it, pointing to packages/select for the usage example and options documentation:

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

That import is the whole example the root README gives for select. The options object, including message and choices, is documented in the per-package README rather than in the root file, so read packages/select before relying on any key beyond the ones shown there.

The old inquirer package is still there, and that is the migration trap

The README is explicit that the previous version of the package is still maintained but not actively developed, and that it offered hundreds of community contributed prompts that might not have been migrated to the latest API. That sentence is the single most important constraint for anyone evaluating this project.

If your CLI depends on a prompt type that exists only in the old package, the rewrite does not help you. You have three options: stay on the old package and accept that it is maintained rather than developed, port the prompt yourself, or redesign the question so a migrated prompt can ask it. None of those is free, and the README does not offer a compatibility shim that lets old prompt definitions run against the new API. The repository does keep the old code under packages/inquirer, so the source is available, but availability is not the same as support.

This is a genuine trade-off rather than a defect. Dropping the community prompt surface is what made a smaller, faster core possible. It just means the upgrade path is per-prompt, not per-project.

Localization through @inquirer/i18n

The README documents a separate package, @inquirer/i18n, described as a drop-in replacement for @inquirer/prompts with built-in localization. The root import detects the locale from the LANGUAGE, LC_ALL, LC_MESSAGES and LANG environment variables, falling back to the Intl API, and uses English when no supported locale is found. Built-in locales listed are English, French, Spanish, Chinese (Simplified) and Portuguese.

// Drop-in replacement, locale is auto-detected from environment variables
import { input, select, confirm } from '@inquirer/i18n';

The README also describes pinning a language through sub-path imports such as @inquirer/i18n/fr, and APIs named createLocalizedPrompts and registerLocale for adding your own locale. The environment-variable detection is worth thinking about before you ship: it means the language your users see depends on their shell configuration, not on a setting your program controls. A user with LANG set to a locale you have not registered falls back to English, which is a reasonable default but can surprise you during testing if your own shell is configured differently from your users'.

Alternatives and how they differ in approach

The repository's own keyword list names several alternatives, which is a useful starting point. Enquirer is the closest comparison and takes a different approach to the same problem: it is a single package with a prompt registry, where you construct a prompt class and call run, rather than importing a standalone async function per prompt. That registry model is what makes third-party prompt types easier to add, and it is roughly the shape the older Inquirer package had. If extensibility of prompt types matters more to you than a small core, that difference is the one to weigh.

prompts is another name in the keyword list and sits at the other end of the spectrum: a minimal library with a small set of prompt types and no plugin surface. It is a reasonable choice when you need the four or five standard widgets and nothing more, and it avoids the migration question entirely because there is no rewrite to migrate across. readline is the Node built-in named in the same list, and it is the right answer when you need a single line of input and nothing interactive. Reaching for Inquirer.js to read one string is overkill; the built-in covers it without a dependency.

Maintenance, licensing and the cost of upgrading

The repository is not archived, and the last push was on 2026-09-18. The most recent releases listed are [email protected], @inquirer/[email protected] and @inquirer/[email protected], all dated 2026-09-07. The project is published under the MIT license, per both the repository metadata and the root package.json license field. MIT is permissive: it allows commercial use and modification, and it requires that the copyright notice and permission notice be included in copies or substantial portions of the software. That is a general description of the license text, not legal advice; read the LICENSE file in the repository if the distinction matters to your organization.

The upgrade cost is structural rather than incidental. Version numbers do not move in lockstep across the workspace: the meta package inquirer is on 14.x while @inquirer/prompts is on 8.x, so a changelog entry for one does not tell you what changed in the other. A monorepo layout with lerna.json and turbo.json means releases are coordinated across packages, and the root package.json shows a prepack step that rewrites utm_source parameters in package READMEs, which is a sign the publishing pipeline does real work at release time. For a consumer, the practical consequence is that you should read the release notes for the specific package you import, not for the repository as a whole. The README does not document a rollback procedure or a deprecation timeline for the old package beyond the statement that it is maintained but not actively developed.

Editorial conclusion

Adopt @inquirer/prompts for Node.js CLIs that need input, select, checkbox, confirm, password, search, expand, editor, number or rawlist prompts, and expect to import each prompt individually. Do not adopt it if you need a browser UI, a non-Node runtime, or the hundreds of community prompts that only exist in the previous package. Before committing, run npx @inquirer/demo@latest to see the widgets in your terminal, and check whether the specific prompt you need was migrated to the new API or still lives in the old inquirer package.

Frequently asked questions

Official sources

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