CLI Application Development with Commander.js

Quick Guide: Use Commander.js for command structure and option parsing. Use @clack/prompts for interactive UX (spinners, selects, confirms). Always handle Ctrl+C cancellation with p.isCancel(). Use named exit code constants. Use parseAsync() for async actions. Structure commands in separate files. Resolve config with precedence: flag > env > project > global > default.

<critical_requirements>

CRITICAL: Before Building CLI Applications

All code must follow project conventions in CLAUDE.md (kebab-case, named exports, import ordering, import type, named constants)

(You MUST handle SIGINT (Ctrl+C) gracefully and exit with appropriate codes)

(You MUST use p.isCancel() to detect cancellation in ALL @clack/prompts calls and handle gracefully)

(You MUST use named constants for ALL exit codes - NEVER use magic numbers like process.exit(1))

(You MUST use parseAsync() for async actions to properly propagate errors)

(You MUST stop spinners before any console output or error display)

</critical_requirements>

Auto-detection: Commander.js, commander, @clack/prompts, picocolors, p.spinner, p.select, p.confirm, p.text, p.isCancel, p.tasks, p.multiselect, p.group, process.exit, exit codes, SIGINT handling, interactive prompts, wizard state machine, config hierarchy, CLI error handling, parseAsync, subcommand

When to use:

Building command-line tools with Node.js using Commander.js
Creating interactive terminal prompts and wizards with @clack/prompts
Implementing multi-step wizard flows with back navigation
Managing hierarchical configuration (flag > env > project > global)
Structuring CLI applications with subcommands and global options

When NOT to use:

Simple scripts with no user interaction (just use process.argv directly)
Web server frameworks (use your API framework skill)
Single-prompt scripts (use readline or raw @clack/prompts without Commander)

Key patterns covered:

CLI entry point with SIGINT handling and global options
Standardized exit codes with named constants
Command definition with typed options and subcommands
@clack/prompts for interactive UX (spinners, selects, confirms, text)
Cancellation handling (p.isCancel()) on every prompt
Wizard state machines with back navigation
Configuration hierarchy resolution
Dry-run mode implementation

Detailed Resources:

examples/core.md - Entry point, exit codes, commands, prompts, cancellation
examples/wizard-patterns.md - State machines, config hierarchy, dry-run mode

Philosophy

User experience first. CLI tools should be intuitive, provide helpful feedback, and fail gracefully. Users should always know what's happening (spinners), what went wrong (clear errors), and how to fix it (actionable messages).

Consistency across commands. Every command follows the same patterns: options at top, spinner feedback, success/error messaging, and proper exit codes. This makes the CLI predictable and learnable.

Graceful degradation. Always handle cancellation (Ctrl+C), invalid input, and errors. Never leave users in an unknown state. Stop spinners before displaying errors.

When to use Commander.js:

Multi-command CLI tools (git-like interfaces)
Tools with complex option parsing and subcommands
Applications needing auto-generated help text
TypeScript-first development

When to use @clack/prompts:

Interactive setup wizards and multi-step flows
User confirmation before destructive actions
Selection from lists of options
Any user input beyond simple flags

Core Patterns

Pattern 1: CLI Entry Point Structure

Register commands, handle SIGINT, use parseAsync() for async error propagation. See examples/core.md for full implementation.

// Handle Ctrl+C gracefully
process.on("SIGINT", () => {
  console.log(pc.yellow("\nCancelled"));
  process.exit(EXIT_CODES.CANCELLED);
});

// Use parseAsync for proper async error handling
await program.parseAsync(process.argv);

Pattern 2: Standardized Exit Codes

Define all exit codes as named constants. Never use magic numbers. See examples/core.md for the full constant definition.

export const EXIT_CODES = {
  SUCCESS: 0,
  ERROR: 1,
  INVALID_ARGS: 2,
  CANCELLED: 4,
  VALIDATION_ERROR: 7,
} as const;

// GOOD: Named constant
process.exit(EXIT_CODES.VALIDATION_ERROR);

// BAD: Magic number
process.exit(1); // What does 1 mean?

Pattern 3: Command Definition with Options

Structure commands with typed options, descriptions for help text, and global option access. See examples/core.md for full implementation.

export const initCommand = new Command("init")
  .description("Initialize the project")
  .option("--source <url>", "Source URL")
  .option("-f, --force", "Overwrite existing files", false)
  .action(async (options, command) => {
    const globalOpts = command.optsWithGlobals();
    // ...
  });

Pattern 4: Interactive Prompts with Cancellation

Every @clack/prompts call must be followed by p.isCancel(). See examples/core.md for spinner, select, confirm, and text patterns.

const result = await p.select({
  message: "Select a framework:",
  options: [
    { value: "react", label: "React", hint: "recommended" },
    { value: "vue", label: "Vue" },
  ],
});

// CRITICAL: Always check for cancellation
if (p.isCancel(result)) {
  p.cancel("Setup cancelled");
  process.exit(EXIT_CODES.CANCELLED);
}

Pattern 5: Subcommand Organization

Group related commands under parent commands. See examples/core.md for full implementation.

export const configCommand = new Command("config").description(
  "Manage configuration",
);

configCommand
  .command("show")
  .description("Show current effective configuration")
  .action(async () => {
    /* ... */
  });

configCommand
  .command("set")
  .argument("<key>", "Configuration key")
  .argument("<value>", "Configuration value")
  .action(async (key, value) => {
    /* ... */
  });

Pattern 6: Wizard State Machine

Complex multi-step flows with back navigation. See examples/wizard-patterns.md for full state machine implementation.

const state = createInitialState();

while (true) {
  switch (state.currentStep) {
    case "approach": {
      const result = await stepApproach(state);
      if (p.isCancel(result)) return null;
      pushHistory(state);
      state.currentStep = "selection";
      break;
    }
    case "selection": {
      const result = await stepSelection(state);
      if (result === BACK_VALUE) {
        state.currentStep = popHistory(state) || "approach";
        break;
      }
      // ...
    }
  }
}

Pattern 7: Configuration Hierarchy

Resolve config values with clear precedence: flag > env > project > global > default. See examples/wizard-patterns.md for full implementation.

export async function resolveSource(
  flagValue?: string,
  projectDir?: string,
): Promise<ResolvedConfig> {
  if (flagValue !== undefined)
    return { source: flagValue, sourceOrigin: "flag" };

  const envValue = process.env[SOURCE_ENV_VAR];
  if (envValue) return { source: envValue, sourceOrigin: "env" };

  // ... project config, global config, default
}

Pattern 8: Dry-Run Mode

Preview operations without executing. See examples/wizard-patterns.md for full implementation.

export async function executeWithDryRun(
  dryRun: boolean,
  operations: Array<{ description: string; execute: () => Promise<void> }>,
): Promise<void> {
  if (dryRun) {
    for (const op of operations) {
      console.log(pc.yellow(`[dry-run] Would: ${op.description}`));
    }
    return;
  }
  // Execute for real with spinner feedback
}

<decision_framework>

Decision Framework

Command Structure Decision

Is it a single operation?
├─ YES → Single command with options
└─ NO → Are operations related?
    ├─ YES → Subcommands under parent (config show, config set)
    └─ NO → Separate top-level commands

User Input Decision

Does user need to provide input?
├─ NO → Use options/flags only
└─ YES → Is it a simple yes/no?
    ├─ YES → p.confirm()
    └─ NO → Is it choosing from options?
        ├─ YES → p.select() or p.multiselect()
        └─ NO → Is it free-form text?
            └─ YES → p.text() with validation

Async Operation Feedback

Is operation quick (< 500ms)?
├─ YES → No spinner needed
└─ NO → Use p.spinner() with:
    ├─ start("Descriptive message...")
    ├─ stop("Success with result info")
    └─ Error: stop first, then p.log.error()

Config Value Resolution

Check in order, first defined wins:
1. --flag (CLI argument)
2. ENV_VAR (environment variable)
3. ./.myapp/config.yaml (project config)
4. ~/.myapp/config.yaml (global config)
5. DEFAULT_VALUE (hardcoded default)

</decision_framework>

<red_flags>

RED FLAGS

High Priority Issues:

Missing p.isCancel() checks after prompts — causes undefined behavior on Ctrl+C
Using magic numbers for exit codes — makes debugging impossible
Not handling SIGINT — leaves processes in unknown state
Using .parse() instead of .parseAsync() with async actions — swallows errors silently

Medium Priority Issues:

Missing spinner feedback for operations > 500ms
Inconsistent error message formatting across commands
Missing --help descriptions for options
Not stopping spinner before showing error output — corrupts terminal display

Common Mistakes:

Forgetting to call process.exit() after p.cancel() — execution continues past cancellation
Not validating inputs early — errors occur deep in flow where recovery is harder
Not cleaning up on errors (spinners left running, terminal state corrupted)
Using program.parse() then trying to catch errors — parseAsync() required for async error propagation

Gotchas & Edge Cases:

Commander converts --my-option to myOption in camelCase automatically
optsWithGlobals() needed to access parent command options (not just opts())
Spinner must be stopped before any console.log / p.log output
process.exit() in async context may not wait for pending I/O — use await before exit-triggering operations
Commander v13+ defaults allowExcessArguments to false — extra positional args are now errors
@clack/prompts spinner has .isCancelled property and .cancel() / .error() methods for richer feedback

</red_flags>

<critical_reminders>

CRITICAL REMINDERS

All code must follow project conventions in CLAUDE.md