export declare function isPnpmfilePath(filePath: string): boolean; export interface PnpmfileInfo { /** * Absolute path to the pnpmfile. */ path: string; /** * Why the file is not safe to include in a code bundle, when it isn't. * Only self-contained pnpmfiles (see {@link analyzePnpmfile}) are * bundleable: the remote install loads the pnpmfile before any * dependencies are installed and in a different environment, so a * pnpmfile that depends on anything outside its own bytes would turn * today's silent lockfile re-resolution into a hard remote install * failure. `undefined` means the file is bundleable. */ skipReason?: string; } /** * Discovers the pnpmfile pnpm would use for the workspace and determines * whether it can be bundled. Mirrors pnpm's own resolution: * * - Bundling only matters — and is only safe — when the lockfile records a * `pnpmfileChecksum`: without one there is nothing for the remote install * to reproduce, and shipping a pnpmfile alongside a lockfile that does * not record its checksum would itself make pnpm treat the lockfile as * out of date. When the lockfile records no checksum, no pnpmfiles are * reported at all (no bundling, no warnings). * - When the `pnpmfile` setting points at custom paths, pnpm loads those * and ignores the default filenames. Custom paths are reported as * non-bundleable (except a single setting that just names a default * file at the root, which is treated like the default). * - Otherwise the default filenames apply. When both `.pnpmfile.mjs` and * `.pnpmfile.cjs` exist, the effective file depends on the pnpm version * (pnpm 11 loads only the mjs, pnpm 10 only the cjs), so the situation * is ambiguous and both are skipped. * * Never throws: any inspection error is reported as a skip reason so that * workspace detection keeps working for commands that never bundle. */ export declare function loadWorkspacePnpmfiles(rootPath: string, configFilePath?: string, lockfilePath?: string): Promise;