Configuration reference

Name of the compiled binary. Determines the executable filename, the Cargo [[bin]] target name, and the environment-variable prefix used for TLS, proxy, and logging settings.

When omitted, the generator derives the name from the API definition’s display name (kebab-cased). Multi-spec workspaces must set this field explicitly — there is no sensible auto-derivation when multiple specs are present.

1
config:
2
  binaryName: contoso

The binary name contoso produces:

• Executable: contoso
• Env-var prefix: CONTOSO (e.g. CONTOSO_CA_BUNDLE, CONTOSO_LOG)

Controls whether the generator produces the custom command infrastructure alongside the CLI binary. When enabled, the output includes:

• A <binaryName>-types library crate (typed serde structs)
• A <binaryName>-sdk library crate (HTTP client accessible via ctx.client())
• Scaffolding files for user-authored command handlers

Set to false to produce a spec-only CLI with no custom command support.

1
config:
2
  customCommands: false

Renames the global flag (and its derived environment variable) that a downstream consumer uses to append a product token to the generated CLI’s User-Agent. Provide the flag’s long name without the leading --. It must be a kebab identifier matching ^[a-z][a-z0-9-]*$ and can’t collide with a built-in flag name.

Any kebab identifier is accepted except the CLI’s built-in flag names (params, output, json, format, dry-run, base-url, page-all, page-limit, page-delay, no-pager, no-extract, no-retry, no-stream, quiet, query, help, debug, schema). The default user-agent-suffix exposes --user-agent-suffix and <NAME>_USER_AGENT_SUFFIX. For example, setting via exposes --via and <NAME>_VIA instead (the environment variable is <NAME>_ followed by the flag uppercased with hyphens converted to underscores):

1
config:
2
  userAgentSuffixFlag: via

A consumer of the generated contoso CLI then appends its product token with the renamed flag:

$
contoso plants list --via "partner-app/3.1"
$
# sends User-Agent: contoso-cli/1.4.0 partner-app/3.1

Generates a wiremock-based integration test suite alongside the CLI. When enabled, generation emits a wire_test.rs harness and a wire-test-cases.json manifest with one case per endpoint example. Each test starts an in-process mock server, drives the compiled binary, and asserts the command hit the expected method and path and rendered the mocked response. The generated CI runs the suite with cargo test.

Only commands derived from the API spec are covered; custom commands aren’t.

1
config:
2
  generateWireTests: true

Splits the generated types into one crate per API, plus a shared core crate for types that more than one API references, nested inside <binaryName>-types/crates/. By default, every generated model lands in a single <binaryName>-types crate.

Enable it for workspaces with many specs, where that single crate is one rustc compilation unit large enough to exhaust the memory of a standard CI runner and get cargo build killed. Splitting also shortens builds, because the per-API crates compile in parallel and cache independently. <binaryName>-types remains as a facade that re-exports everything, so imports such as use plant_types::Plant; keep resolving and custom command handlers need no changes. The shipped artifact is the same either way: one binary with every spec embedded.

1
config:
2
  binaryName: plant
3
  splitTypeCrates: true

Sets the Cargo [package] metadata of the generated crate. Use packageIdentity to publish the crate under your own name, license, repository, and authors instead of Fern’s.

1
config:
2
  binaryName: plant
3
  packageIdentity:
4
    name: plant-cli
5
    description: Command-line interface for the Plant API.
6
    license: MIT
7
    repository: https://github.com/garden/plant-cli
8
    homepage: https://example.com
9
    authors: ["Plants <support@garden-plants.com>"]
10
    keywords: ["plants", "cli"]

Adds Homebrew and Scoop publishing on top of the GitHub Release archives every generated CLI already ships. Both channels install from a tagged release, so distribution is honored only when the generator delivers to a GitHub repository through the github block. Enabling a channel adds a publish job to the release workflow and the matching install command to the generated README. Each job pushes to a public tap or bucket repository you create, authenticating with either a personal access token per channel or a GitHub App whose credentials you store as repository secrets.

1
config:
2
  binaryName: plant
3
  distribution:
4
    homebrew:
5
      tap: garden/homebrew-tap
6
      formula: plant
7
    scoop:
8
      bucket: garden/scoop-bucket