-
Notifications
You must be signed in to change notification settings - Fork 232
Proposal: Declarative YAML form generator (charm-form) #761
Copy link
Copy link
Open
Description
Problem
Building interactive CLI forms with huh requires Go knowledge. But many use cases just need a simple form:
- DevOps scripts that need user input
- Installation wizards
- Configuration prompts
- Onboarding flows
These should be as easy as writing a YAML file.
Proposed Solution
charm-form — define forms in YAML, get interactive CLI apps powered by huh.
Define your form
# deploy.yaml
title: Deploy Configuration
fields:
- name: environment
type: select
label: Target Environment
options: [staging, production]
required: true
- name: version
type: input
label: Version
placeholder: "v1.0.0"
validate: "^v\d+\.\d+\.\d+$"
- name: dry_run
type: confirm
label: Dry run only?
- name: services
type: multiselect
label: Services to deploy
options: [api, web, worker]Run it
charm-form run deploy.yaml
# → Interactive huh form appears
# → Outputs JSON with answersSupported Field Types
| Type | huh Equivalent |
|---|---|
| `input` | huh.Input |
| `text` | huh.Text (multiline) |
| `select` | huh.Select |
| `multiselect` | huh.MultiSelect |
| `confirm` | huh.Confirm |
Features
- YAML spec with validation (required fields, regex patterns)
- `LoadFromFile()` and `LoadFromBytes()` for programmatic use
- JSON output for easy integration with shell scripts
- Strict validation on load (invalid types, missing options, etc.)
Working POC
https://github.com/junhinhow/charm-form
Bilingual docs (EN/PT-BR).
Questions
- Would this complement huh or overlap too much?
- Interest in a `huh.FromYAML()` function directly in huh?
- Should we support JSON/TOML specs too, or keep it YAML-only?
Reactions are currently unavailable
Metadata
Metadata
Assignees
Labels
No labels