survey

Survey is a Go library for building interactive command-line prompts. It provides a set of composable prompt types — Input, Password, Confirm, Select, MultiSelect, Multiline, and Editor — that can be run individually with AskOne or chained together as a full questionnaire with Ask, writing answers directly into a struct via reflection and struct tags.

The library handles the low-level terminal concerns that make interactive CLIs tricky to build correctly: raw-mode input handling, ANSI rendering, cursor positioning, and pagination of long option lists, all while working consistently across POSIX and Windows terminals. On top of that it layers validators (Required, MinLength, MaxLength, MinItems, MaxItems), answer transformers, custom filtering, and configurable icon sets, so teams can standardize the look and validation rules of their CLI prompts without re-implementing terminal handling themselves.

The project’s README states it is no longer actively maintained by its original author, who points users toward charmbracelet/bubbletea as a modern alternative. It remains widely used and vendored by existing Go CLI tooling, but teams starting new projects should weigh that maintenance status against active alternatives.

What You Get

• Seven prompt types out of the box: Input, Password, Confirm, Select, MultiSelect, Multiline, and Editor
• Struct-tag-based answer binding so Ask writes an entire questionnaire’s responses directly into a typed struct
• Built-in validators (Required, MinLength, MaxLength, MinItems, MaxItems) composable via survey.WithValidator
• Custom filter functions and pagination for long Select/MultiSelect option lists, with configurable page size
• Per-option Description callbacks and input auto-suggestion support for the Input prompt
• Consistent behavior across POSIX and Windows terminals through an internal cross-platform terminal abstraction

Common Use Cases

• Scaffolding CLIs (project generators, framework installers) that ask setup questions interactively
• Building interactive git/deployment-style tools that need confirm-before-destructive-action prompts
• Collecting structured configuration (name, environment, feature flags) into a single answers struct for downstream code
• Presenting long enumerable choices (branches, environments, regions) as paginated, filterable select lists
• Launching a full external editor from a CLI for multi-line free-form input, like a commit message editor

Under The Hood

Architecture The library is organized as a flat package (survey) with two supporting subpackages: core, which owns text-template rendering (RunTemplate) and the OptionAnswer type shared across prompts, and terminal, which abstracts raw-mode input/output, cursor movement, and platform-specific rune reading behind a single Stdio-based interface with separate POSIX/Windows implementations. Each prompt type (Select, Input, Confirm, etc.) embeds a shared Renderer that owns template execution and diff-based re-rendering of the current prompt state, so a change to one answer only repaints the affected lines rather than the whole screen. Ask/AskOne sit on top as the orchestration layer: they iterate a slice of *Question, run each Prompt.Prompt() implementation, apply transformers and validators, and use reflection to write results into caller-supplied struct fields matched by name or survey tag. Because prompts communicate through this uniform Prompt interface and a shared PromptConfig, adding a new prompt type is additive rather than invasive to existing ones. Tech Stack Written in Go (module github.com/AlecAivazis/survey/v2, targeting Go 1.13) with a small, deliberately minimal dependency set: golang.org/x/term for raw terminal mode, golang.org/x/text for text handling, mgutz/ansi for ANSI color codes, mattn/go-isatty/go-colorable for terminal detection, and kballard/go-shellquote for editor command parsing. Test-only dependencies include Netflix/go-expect and hinshun/vt10x for terminal-emulation-based integration tests, plus stretchr/testify for assertions. There is no external runtime framework — the library owns its own rendering and input loop rather than delegating to a bubbletea-style TUI framework. Code Quality The project ships a substantial test suite (16+ _test.go files) split between unit tests of individual prompt logic and higher-level tests that drive a simulated terminal via go-expect/vt10x to assert on actual rendered output and keystroke sequences — a comprehensive approach for a terminal UI library where visual/interactive behavior is otherwise hard to verify. Errors are returned explicitly (idiomatic Go error returns) rather than panicking, validators return typed errors surfaced back to the user in-place, and CI (GitHub Actions) runs the suite across three OS platforms and four Go versions, indicating attention to cross-platform correctness. Naming is consistent and idiomatic; there is no separate linter step configured in CI, though. What Makes It Unique Survey’s specific niche is single-purpose interactive prompting rather than general TUI construction — it doesn’t provide layout, styling themes, or a component-based rendering model the way a full TUI framework does; instead it focuses narrowly on the question-and-answer prompt pattern (validators, transformers, struct-tag binding, and diff-based re-rendering of just the active prompt) that most CLI tools actually need. Its own README candidly signals that the ecosystem has moved toward broader frameworks like bubbletea for building richer terminal UIs, positioning survey as a mature, focused, but no-longer-actively-evolving building block for the narrower prompt use case.