Skip to content

bug(search): documented --pretty option is rejected #181

Description

@DanielleWashington

Summary

firecrawl search documents and internally supports a --pretty output option, but the command does not register the flag. The released CLI therefore rejects documented Search examples before making an API request.

Reproduction

Environment:

  • firecrawl-cli@1.19.29
  • Node.js v24.18.0
  • npm 11.16.0

Run:

npm exec --yes --package firecrawl-cli@1.19.29 -- \
  firecrawl search "test" --pretty

Actual result:

error: unknown option '--pretty'

No API key is needed to reproduce this because argument parsing fails before any request. firecrawl search --help lists --json but not --pretty.

Expected behavior

firecrawl search ... --pretty should emit indented JSON, consistent with the documented contract, the Search option type, the Search output handler, and other CLI commands that expose --pretty.

Current source

At firecrawl/cli@c0560791deb920e45fe9ccde26f7e7973c92a5f2 (package.json version 1.19.29):

  • src/index.ts comments out the Search --pretty registration but registers --json.
  • The same command still passes options.pretty into handleSearchCommand.
  • src/types/search.ts includes pretty?: boolean.
  • src/commands/search.ts already formats indented JSON when options.pretty is true.

Current Firecrawl documentation still advertises Search --pretty in the CLI option table and multiple Search snippets, including the basic example.

Suggested fix

Restore the Search -p, --pretty registration and add command-level coverage proving that:

  1. firecrawl search --help lists --pretty.
  2. firecrawl search "test" --pretty reaches the Search handler instead of failing option parsing.
  3. Pretty mode emits indented JSON and implies JSON output.

If the option was intentionally removed, the alternative is to remove the remaining pretty handler/type path and update every affected documentation snippet. Given that implementation support already exists and other commands expose the same option, restoring the registration appears to be the smaller consistency fix.

Duplicate check

No matching open or closed issue was found in firecrawl/cli using repository issue searches for pretty search and the broader term pretty on 2026-08-06.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions