Planning: playwright-rs-cli crate

[padamson]

Planning issue for a future `playwright-rs-cli` crate. Not scheduled for any specific release; this is a design / scoping placeholder.

Why a CLI

The Playwright JS CLI handles codegen, the recorder, the trace viewer, and the inspector. Reimplementing those wholesale in Rust is a months-long product, not a feature. The interesting question is what unique value a Rust CLI offers — the candidates are:

• Interactive REPL on top of `playwright-rs::Debugger` + `pick_locator`. A short-feedback-loop tool for exploring a page from a terminal: arm the debugger, click an element, get the resolved locator pasted back as Rust code, step through actions. The closest JS equivalent is the Inspector's interactive panel, but a TUI version that emits Rust snippets has a clear audience.
• Trace-file consumer. Open a Playwright trace zip from disk, navigate the action graph, dump action metadata as JSON or rendered text. Closest analogue: the JS `npx playwright show-trace`, but headless and scriptable.
• `screencast` recorder/viewer. Once `Page::screencast` lands (#TODO once filed), a CLI wrapper that streams frames to disk or to a TUI preview is the kind of thing other bindings don't have.

Crate-layout questions to answer before implementing

• Workspace member or separate repo?
• Independent versioning from `playwright-rs` (definitely yes, but how locked is the dependency? `playwright-rs = "0.13"` or git-pinned?)
• Binary distribution: cargo install only, or also pre-built binaries via release.yml?
• Feature-flag the optional surfaces (e.g. `tui`, `screencast`)?

Out of scope for now

Recreating playwright-cli's recorder mode (it's a JS-side instrumentation that injects scripts into the page). The Rust binding has `pick_locator` for the same use case at a smaller scope.

Next step

When we're ready to start, this issue gets promoted to a milestone with an explicit scope and a target release.

[padamson]

A first-cut CLI binary landed in a38c472, but in a narrower shape than this issue's larger vision — worth noting here so the planning context stays accurate.

What shipped:

• Binary playwright-rs (matches the crate name; standard Rust convention; no PATH collision with npm/pip playwright).
• Lives inside the playwright-rs crate as a [[bin]] behind a cli feature, not a separate playwright-rs-cli crate.
• Single subcommand: playwright-rs install [BROWSERS]... [--with-deps] [--driver-only]. Downloads the Playwright driver into dirs::cache_dir()/playwright-rust/<version>/ and then calls the existing install_browsers_with_deps() API.
• Discoverable via cargo install playwright-rs --features cli.
• Motivated by the $OUT_DIR driver migration: downstream binaries distributed via cargo install need a user-cache driver bootstrap because their compile-time-embedded OUT_DIR path is invalidated when cargo install cleans up the build tree. The runtime resolution chain in src/server/driver.rs was extended with a try_user_cache_driver() step that this bin populates.

What this answers from the crate-layout questions:

• Workspace member or separate repo? → in-crate [[bin]] for now. Splitting out a playwright-rs-cli member crate is a deferrable refactor once subcommands grow.
• Independent versioning? → N/A while in-crate; would matter if it splits.
• Binary distribution? → cargo install only, via the cli feature.
• Feature-flag optional surfaces? → yes; single cli feature for now; sub-features (tui, trace-viewer, screencast) can layer on top.

What this issue's larger scope still covers:

• Interactive REPL on top of Debugger + pick_locator (TUI exploration with Rust-snippet codegen).
• Trace-file consumer (CLI subcommand layered on the new playwright-rs-trace crate).
• screencast recorder/viewer (CLI subcommand on top of Page::screencast).

Suggested next step for this issue:

Re-scope to "expand the playwright-rs bin's subcommand surface" rather than "create a playwright-rs-cli crate." The crate-extraction question becomes a downstream decision once subcommand count / dep weight justifies it (e.g. if trace-viewer pulls in heavy parsing-and-rendering deps that don't belong in the main crate's default tree). For now, the architecture is playwright-rs install as the seed, with playwright-rs driver path, driver version, etc. reserved for non-breaking additions.