Subcommand
The object you pass to defineSubcommand.
| Property | Type | Description |
|---|---|---|
name | string | The name used to call it. Must be unique across all names and aliases in the CLI. |
aliases? | string[] | Extra names for the same subcommand. Same uniqueness rule. |
options? | Record<string, Option> | Options keyed by name, so inputDir becomes --input-dir. |
arguments? | Record<string, Argument> | Typed arguments, in the order they are read. |
allowPositionals? | boolean | Collect leftover input as an untyped string[]. Typed arguments are filled first. |
meta? | SubcommandMeta | Text used by help output and generated docs. |
SubcommandMeta
| Property | Type | Description |
|---|---|---|
placeholder? | string | Shown after the name to hint at the expected input, for example <list> <items>. |
usage? | string | Usage line, for example listy add-items [options] <list>. Terminal help only. |
description? | string | Plain text. Supports multiple lines and ANSI colors. Preferred in terminal help. |
descriptionMarkdown? | string | Markdown. Preferred in generated Markdown, and formatted when printed to a terminal. |
example? | string | Examples. Shown at the bottom of terminal help, inside a code block in Markdown. |
hidden? | boolean | Leave the subcommand out of help and docs. Useful for internal commands. |
Returned methods
defineSubcommand returns the definition with onExecute, execute, and executeAsync attached. They behave exactly as they do on the CLI. See Cli.
Every subcommand also gets generateCliHelpMessage and generateSubcommandHelpMessage, on the first run or runAsync call of the CLI that it belongs to.
A subcommand has no run method. Terminal input always goes through the CLI, which routes it to the right subcommand.