export type PackageManager = 'pnpm' | 'yarn' | 'npm';
/**
 * Decide from the project's lockfile. npm is the fallback: it is what ships with Node, so it is
 * the right guess for a tree with no lockfile at all — one assembled by hand, or one whose
 * `bitmagic init` install never got to write one.
 *
 * Checked most-specific-first — a repo can carry both a `pnpm-lock.yaml` and a leftover
 * `package-lock.json`, and pnpm is the one actually in use there.
 *
 * Note this reads a fact about an EXISTING project, which is why `bitmagic init` preferring pnpm
 * (`preferredInstallManager`) changes nothing here: the install writes a lockfile, and from then
 * on the lockfile is the answer. A project scaffolded before that change keeps its
 * `package-lock.json` and keeps being told about npm, which is what its tree actually wants.
 */
export declare function detectPackageManager(root: string): PackageManager;
/**
 * The command that adds `specs` as (dev) dependencies. yarn's syntax differs from npm's and
 * pnpm's (`yarn add --dev`, not `--save-dev`), which is why this is a function rather than a
 * template string at each call site.
 */
export declare function addCommand(manager: PackageManager, dev: boolean, specs: string[]): string;
/** The command that installs everything already declared in package.json. */
export declare function installAllCommand(manager: PackageManager): string;
/** Whether a command answers `--version`, i.e. is on this machine's PATH and runnable. */
export type CommandProbe = (command: string) => boolean;
/**
 * The manager a BRAND-NEW project should be installed with: pnpm when the machine has it, npm
 * otherwise.
 *
 * pnpm is preferred because it is what this project's own tooling is built and tested against,
 * and because its stricter linking surfaces a dependency the project uses but never declared —
 * npm's hoisting hides exactly that until a published bundle is missing a module.
 *
 * It is a preference rather than a requirement because npm ships with Node and pnpm does not.
 * Scaffolding is the creator's first command; failing it over a package manager, when the very
 * next thing the CLI does is write a complete and valid project to disk, would be the wrong
 * trade. The lockfile the install writes is what every later message reads
 * (`detectPackageManager`), so a project is self-consistent whichever branch it took.
 */
export declare function preferredInstallManager(probe?: CommandProbe): PackageManager;