/** A spawnable blueprint-compiler, plus how it was found (for `verbose`). */
export interface ResolvedBlueprintCompiler {
    /** The executable to spawn. */
    file: string;
    /** Arguments that must precede blueprint-compiler's own (e.g. the script path). */
    prefixArgs: string[];
    /** Environment overlay to spawn with, or undefined to inherit unchanged. */
    env?: Record<string, string>;
    source: 'env' | 'path' | 'msys2';
}
/**
 * The host facts this module decides on, taken as a PARAMETER rather than read
 * from ambient `process.*`.
 *
 * Every unit-test leg in this repo runs on Linux, so an ambient
 * `process.platform` puts the darwin and win32 branches — which are most of this
 * module and the only ones anybody gets wrong — out of reach of any test. This
 * is the purity `packages/infra/cli/src/utils/platform-check.ts` documents,
 * applied to the module whose entire job is a per-OS answer.
 */
export interface BlueprintHost {
    /** `process.platform` of the host being answered for. */
    platform: NodeJS.Platform;
    /** That host's environment. */
    env: Record<string, string | undefined>;
    /** Does this path exist? `existsSync` in production, a map in a test. */
    exists: (path: string) => boolean;
}
/** The running process as a {@link BlueprintHost}. */
export declare function currentBlueprintHost(): BlueprintHost;
/**
 * Locate a usable blueprint-compiler, or null when there is none.
 *
 * Order: `BLUEPRINT_COMPILER` (an explicit answer always wins, and is the escape
 * hatch for an install none of the probes below know about) → `PATH` → an MSYS2
 * install on win32.
 *
 * A set-but-unusable override resolves to null rather than falling through to
 * the probes. Handing back a path that is not there sent its `ENOENT` into the
 * "the compiler EXISTS and refused the file" branch, which then blamed the
 * `.blp` for a typo in an environment variable; and quietly ignoring an explicit
 * instruction to run a second guess is not better. Null is what lets
 * {@link formatMissingBlueprintCompiler} say which of the two actually happened.
 */
export declare function resolveBlueprintCompiler(host?: BlueprintHost): ResolvedBlueprintCompiler | null;
/**
 * What to tell someone who has no blueprint-compiler.
 *
 * Names the install command for THIS platform rather than listing every one:
 * the reader is on one host and the other two lines are noise they have to
 * filter. The Linux arm is the exception that proves it — every Linux row of
 * `PM_PACKAGES` in `@gjsify/cli`'s `check-system-deps.ts` spells the package
 * identically, so splitting it per distro would be four lines carrying one word.
 *
 * `BLUEPRINT_COMPILER` is mentioned everywhere because it is the answer for any
 * install the probes miss — except when it is itself the problem, which gets its
 * own sentence: repeating "or set BLUEPRINT_COMPILER" at someone who just set it
 * is how a diagnostic loses their trust.
 */
export declare function formatMissingBlueprintCompiler(host?: BlueprintHost): string;
/**
 * No usable compiler on this host.
 *
 * Carries the whole user-facing sentence so the wording has exactly one home and
 * the plugin composes nothing: what this replaces was an `ExecaError` naming the
 * COMMAND, in the guest's own language, from inside a rolldown plugin stack
 * (#1098).
 */
export declare class BlueprintCompilerNotFoundError extends Error {
    readonly blueprintPath: string;
    readonly name = "BlueprintCompilerNotFoundError";
    constructor(blueprintPath: string, host?: BlueprintHost);
}
/**
 * The compiler exists and refused the file, so this is a blueprint syntax or
 * type error and its own stderr is the useful part — never an install hint the
 * reader has already satisfied.
 */
export declare class BlueprintCompileError extends Error {
    readonly blueprintPath: string;
    readonly compilerFile: string;
    readonly name = "BlueprintCompileError";
    constructor(blueprintPath: string, compilerFile: string, detail: string);
}