feat(cli): improve interactive prompt UI with @clack/prompts

[mrgrain]

Improves the interactive CLI experience for deploy approvals, text prompts, and the flags command by adopting @clack/prompts — a modern, actively maintained prompt library with beautiful default styling.

The CLI previously relied on promptly and enquirer for user interaction, both of which are unmaintained and produce plain, unstyled output. @clack/prompts provides a consistent, visually polished prompt experience out of the box, with clear confirmation dialogs, styled select menus, and proper cancellation handling via Ctrl+C.

Beyond the immediate UI improvements, this also lays the groundwork for richer CLI interactions in the future. @clack/prompts ships with spinner, taskLog, and structured logging utilities that can be used to improve deploy progress, asset upload feedback, and other long-running operations.

Before / After

Deploy approval

Before

After

Flags interactive menu

Before

After

Text input

Before

After

---

Since @clack/prompts is an ESM-only package and Jest runs in CJS mode, a global mock file is provided at test/_helpers/mock-clack-prompts.js. This is appropriate because prompt functions are inherently interactive and should always be mocked in tests. The bundled CLI binary is unaffected since esbuild handles ESM→CJS interop at build time.

Fixes #

Checklist

• This change contains a major version upgrade for a dependency and I confirm all breaking changes are addressed
  • Release notes for the new version: N/A — this replaces two packages with a new one, not an upgrade

---

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license

[codecov-commenter]

Codecov Report

❌ Patch coverage is 72.88136% with 16 lines in your changes missing coverage. Please review.
✅ Project coverage is 88.20%. Comparing base (7ce6a36) to head (a06c7e8).
⚠️ Report is 106 commits behind head on main.

Files with missing lines	Patch %	Lines
.../aws-cdk/lib/commands/flags/interactive-handler.ts	64.51%	11 Missing ⚠️
packages/aws-cdk/lib/cli/io-host/cli-io-host.ts	82.14%	4 Missing and 1 partial ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #1370      +/-   ##
==========================================
- Coverage   88.31%   88.20%   -0.12%     
==========================================
  Files          74       74              
  Lines       10430    10458      +28     
  Branches     1427     1432       +5     
==========================================
+ Hits         9211     9224      +13     
- Misses       1191     1206      +15     
  Partials       28       28              

Flag	Coverage Δ
suite.unit	88.20% <72.88%> (-0.12%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[kaizencc]

🐝 is using @clack/prompts the best thing to do here?

[we-are-the-hive]

🐝 The Hive Has Spoken

Question: "is using @clack/prompts the best thing to do here?"

Options considered:

• Keep @clack/prompts — Continue with the @clack/prompts migration as proposed, leveraging its modern ESM architecture, built-in styling, and comprehensive prompt types (confirm, select, text, spinner). This approach provides immediate UX improvements with minimal technical debt, while the ESM-only nature is handled via Jest mocks and esbuild bundling for the CLI binary. The library's active maintenance and rich feature set (taskLog, spinner utilities) enable future CLI enhancements.
• Custom Prompt System — Build an internal prompt abstraction layer using native Node.js readline and process.stdout/stdin for maximum control over CLI interactions. This would implement custom styling via ANSI escape codes, provide tailored prompt types specific to CDK workflows, and eliminate external dependencies for core user interactions. The system could integrate directly with CDK's existing logging and error handling patterns.
• Ink React CLI — Adopt Ink (React for CLI) to build rich, interactive terminal interfaces using familiar React patterns and components. This approach would enable sophisticated layouts, real-time updates during deployments, and reusable UI components across different CLI commands. Ink handles terminal rendering, state management, and user input through a declarative component model that could integrate with CDK's existing React-based constructs documentation.
• Hybrid Prompt Strategy — Maintain lightweight prompts using a stable, CommonJS-compatible library like 'prompts' for basic interactions, while building custom components for complex CDK-specific workflows like deployment approval matrices and resource diff visualization. This approach combines proven libraries for standard prompts with purpose-built interfaces for domain-specific interactions, avoiding ESM compatibility issues.
• Terminal UI Framework — Implement a comprehensive terminal UI using blessed or similar ncurses-like library to create full-screen interactive interfaces with panels, menus, and real-time status updates. This would transform the CLI from prompt-based interactions to dashboard-style interfaces showing deployment progress, resource status, and interactive navigation through CDK applications and stacks.

Winner: Custom Prompt System (1 round)

The hive chose a Custom Prompt System because it provides complete control over the developer experience without introducing external dependencies that could create ESM compatibility issues or lock the project into non-standard patterns. The group prioritized owning their CLI interaction primitives similar to how they maintain control over their construct APIs, avoiding potential silent failures and framework complexity.

Debate details

Round 1: Custom Prompt System(25) · Hybrid Prompt Strategy(19) · Keep @clack/prompts(16) · Ink React CLI(0) · Terminal UI Framework(0)

[we-are-the-hive]

🐝 The Hive Has Spoken

Question: "is using @clack/prompts the best thing to do here?"

Options considered:

• Keep @clack/prompts — Proceed with @clack/prompts as proposed, accepting the ESM-only dependency and Jest mocking complexity. This modern library provides superior UX with beautiful styling, active maintenance, and extensible features like spinners and task logging. The ESM/CJS interop is handled at build time by esbuild, and test mocking is appropriately isolated.
• Custom Prompt System — Build a lightweight, purpose-built prompt system tailored specifically to CDK's needs using native Node.js readline and process.stdout styling. This would provide full control over the UX, eliminate third-party dependencies, and ensure long-term stability. Implementation would focus on the specific prompt types needed: confirmations, selects, and text inputs.
• Ink React CLI — Adopt Ink to build CLI prompts using React components, enabling rich interactive UIs with familiar component patterns. This approach would provide maximum flexibility for complex interactions and leverage the team's React expertise. Ink handles terminal rendering efficiently and supports sophisticated layouts, animations, and state management.
• Hybrid Prompt Strategy — Use lightweight CJS-compatible libraries like 'prompts' for basic interactions and selectively integrate @clack/prompts only for advanced features like deploy progress and spinners. This minimizes ESM complexity while still gaining modern UX benefits where they matter most. Basic prompts remain simple and testable.
• Terminal UI Framework — Implement a comprehensive TUI using libraries like blessed or neo-blessed to create a full-screen terminal application for complex CDK operations. This would provide dashboard-like experiences for deployments, resource management, and configuration. The approach enables rich visual feedback and multiple concurrent operations display.

Winner: Custom Prompt System (1 round)

The hive chose to develop a Custom Prompt System over adopting @clack/prompts to eliminate dependency churn and avoid ESM/CJS interop complications while maintaining explicit control over the prompt interface without surprises from upstream API changes or Node version requirements.

Debate details

Round 1: Custom Prompt System(30) · Hybrid Prompt Strategy(20) · Keep @clack/prompts(10) · Ink React CLI(0) · Terminal UI Framework(0)

[rix0rrr]

Extracting this to a function might be nice, then we don't need the comment anymore.

[rix0rrr]

I believe that they expect only \r as input for ENTER, but this is about output, isn't it? Is this actually true?

[rix0rrr]

Is there a way to turn this into a fake rather than a mock?

[rix0rrr]

If this is true, then how does it work for production code? All our code is CJS, so how do we load an ESM module then? It's only in recent Node versions that CJS can finally directly require() ESM, and I didn't see an await import() ?