import type { AppMigration } from "./index.mjs";
/**
 * What the migration keeps in `.superblocks/` so it can undo itself. The file
 * is persisted across pods (see NPM_TO_PNPM_STATE_RELATIVE_PATH).
 */
export interface NpmToPnpmState {
    /** The `packageManager` value the migration wrote. */
    packageManager: string;
    /** package-lock.json as it was before the migration, null if there was none. */
    packageLock: string | null;
    /** Whether the migration created pnpm-lock.yaml (with pnpm import). */
    wrotePnpmLock: boolean;
    /** Whether the migration created pnpm-workspace.yaml. */
    wrotePnpmWorkspace: boolean;
}
export declare function readPackageJson(cwd: string): Promise<Record<string, unknown>>;
export declare function writePackageJson(cwd: string, pkg: Record<string, unknown>): Promise<void>;
export declare function readState(cwd: string): Promise<NpmToPnpmState>;
/**
 * Converts an npm app to pnpm while pnpm is on for its org: `pnpm import`
 * turns `package-lock.json` into a `pnpm-lock.yaml` with the same versions,
 * package.json gets a `packageManager` field naming the pnpm in the image, and
 * the npm lockfiles go. From then on `detectAppPackageManager` picks pnpm for
 * the app. An app that names a package manager itself is left alone.
 *
 * When pnpm is turned off again, the rollback puts the npm lockfile it kept
 * back and removes what the conversion added, so the next install is npm's.
 * An app created from a template names pnpm without having been converted:
 * it carries package-lock.json beside pnpm's lockfile, and its rollback only
 * drops the packageManager field. Either way the field is gone afterwards, so
 * turning pnpm on again converts the app again. An app that names pnpm and
 * has no npm lockfile was a pnpm app to begin with and is never rolled back.
 */
export declare const npmToPnpm: AppMigration;
//# sourceMappingURL=npm-to-pnpm.d.mts.map