import { type DetectResult } from "package-manager-detector";
import type { LockService } from "@superblocksteam/vite-plugin-file-sync/lock-service";
import type { ApplicationConfigWithTokenConfigAndUserInfo } from "../types/common.js";
export declare const AUTO_UPGRADE_EXIT_CODE = 99;
/**
 * Build the argument vector for the global CLI auto-upgrade install.
 * Extracted so the build path can be tested without driving an exec
 * subprocess.
 *
 * `--fund=false` and `--audit=false` are npm-only (pnpm 12 rejects
 * `--fund`). Userconfig pinning lives in the spawned
 * subprocess env (`NPM_CONFIG_USERCONFIG`) rather than a CLI flag,
 * because pnpm does not accept `--userconfig` (open issue
 * pnpm/pnpm#6036) but does honor the env var through its npm-config
 * compatibility layer. Using the env var means a single mechanism
 * works for both agents.
 */
export declare function buildGlobalInstallArgs(pm: {
    agent: DetectResult["agent"];
}, packageName: string): string[];
/**
 * Build the env overlay for a Superblocks-spawned npm/pnpm subprocess.
 * Pins both `NPM_CONFIG_USERCONFIG` (npm + pnpm <= 10) and
 * `PNPM_CONFIG_USERCONFIG` (pnpm 11+) so the install reads its
 * registry/auth lines from the Superblocks-owned `~/.superblocks/npmrc`
 * instead of the default `~/.npmrc`.
 *
 * Why both: pnpm 11 stopped recognising `npm_config_*` env vars (the
 * @pnpm/npm-conf compatibility layer was tightened) and now requires
 * `pnpm_config_*` for its config keys. pnpm <= 10 honors only the
 * `npm_config_*` form; npm has always honored only the `npm_config_*`
 * form. Setting both is harmless on the agent that ignores one of
 * them. Verified by `userconfig-env.integration.test.mts` against both
 * pnpm 10 and pnpm 11 binaries.
 *
 * The CLI-flag alternative (`--userconfig=` for npm,
 * `--config.userconfig=` for pnpm) would require branching on the
 * agent at every call site; the env-overlay approach is uniform.
 */
export declare function buildInstallEnv(userconfigPath: string, logsDir?: string, baseEnv?: NodeJS.ProcessEnv): NodeJS.ProcessEnv;
/**
 * The package manager that owns the globally installed CLI. The dev-server
 * image installs the CLI as a pnpm global package, whatever the app itself
 * uses, so in the image the upgrade always runs pnpm. Upgrading with npm
 * would install a second CLI under npm's prefix, behind the pnpm one on PATH.
 * The image says so with SUPERBLOCKS_CLI_PNPM_GLOBAL. SUPERBLOCKS_IS_CSB is not
 * enough: the local csb-mock-server sets it on laptops too, where the CLI is
 * whatever the developer installed. There the app's package manager stays the
 * best guess.
 */
export declare function cliPackageManager(appPackageManager: DetectResult): DetectResult;
/**
 * Logs, once per dev-server startup, which @superblocksteam/library version
 * the app's package.json holds after the version check and whether it matches
 * the version the server asked for. The CLI version is on every log record as
 * `service.version`, so this shows library skew per env.
 *
 * `before` and `after` are the package.json specs around the version check;
 * `target` is undefined when the check was skipped or its fetch failed.
 */
export declare function logLibraryVersionCheck({ upgradeMode, before, after, target, }: {
    upgradeMode: string | undefined;
    before: string | undefined;
    after: string | undefined;
    target: string | undefined;
}): void;
export declare function checkVersionsAndWritePackageJson(lockService: LockService, config: ApplicationConfigWithTokenConfigAndUserInfo, forceUpgrade?: boolean, skipCliUpgrade?: boolean, appDir?: string, hasAnyRegistryConfigured?: boolean): Promise<{
    cliUpdated: boolean;
    upgradePromises: Promise<void>[];
    targetLibraryVersion: string | undefined;
}>;
//# sourceMappingURL=automatic-upgrades.d.ts.map