all repos — sz-chrome-remote-cdp @ master

pi-browser-harness, patched to drive a Chrome on another host over CDP, with castle_cdp_search web search

src/cdp/current-target.ts (view raw)

 1
 2
 3
 4
 5
 6
 7
 8
 9
 10
 11
 12
 13
 14
 15
 16
 17
 18
 19
 20
 21
 22
 23
 24
 25
 26
 27
/**
 * The target the harness is actually pointed at, resolved with I/O.
 *
 * `resolveCdpTarget` in endpoint.ts is deliberately pure, so every caller that
 * needs the *effective* target has to read the stored choice first. This wraps
 * that pair so callers outside the CDP layer — profile selection in
 * particular — can ask "am I driving a browser on this machine?" without
 * duplicating the precedence rules.
 */

import { type CdpTarget, resolveCdpTarget } from "./endpoint";
import { readTarget } from "./target-store";

/** The effective target: BU_CDP_HTTP, else /browser-target, else the default. */
export const currentCdpTarget = async (): Promise<CdpTarget> =>
  resolveCdpTarget(process.env, await readTarget());

/**
 * True when the harness is driving a browser on another host.
 *
 * Profile selection is meaningless in that case: it works by launching the
 * browser binary with --profile-directory and letting ProcessSingleton hand
 * the argv to the running browser (see profile/launch.ts), which only reaches
 * a browser on this machine.
 */
export const drivingRemoteBrowser = async (): Promise<boolean> =>
  (await currentCdpTarget()).kind === "remote";