import { FunctionBundler } from "./function-bundle.js";
import { Config, NeonApi, PushResult } from "@neon/config";

//#region src/lib/push-config.d.ts
interface PushConfigOptions {
  /**
   * Neon project id. **Required** — the management API addresses every branch through
   * its project, so there is no way to push without it. `pushConfig` never creates a
   * project; resolve the id yourself (e.g. via neonctl) and pass it in.
   */
  projectId: string;
  /**
   * Neon branch id (`br-…`). **Required.** `pushConfig` never creates a branch — it must
   * already exist on the project. Resolve names to ids before calling.
   */
  branchId: string;
  /** Neon API key. Falls back to `NEON_API_KEY` / neonctl credentials. Ignored when `api` is supplied. */
  apiKey?: string;
  /** Neon API base URL. Falls back to `NEON_API_HOST`, then production. */
  apiHost?: string;
  /**
   * Inject a custom NeonApi adapter. Primarily used by tests; production callers can rely
   * on the default real adapter built from `apiKey`.
   */
  api?: NeonApi;
  /**
   * Whether to evaluate the policy as if the target branch **already exists** (the value of
   * `branch.exists` passed to the `defineConfig({ branch: (branch) => … })` closure). Defaults to `true`.
   *
   * Set to `false` to evaluate the policy as a **branch creation** — used by
   * {@link createBranch} right after it provisions a new branch, so creation-time tuning
   * gated on `!branch.exists` (TTL, compute settings, `parent`) actually resolves instead of
   * hitting the "existing branch, leave as-is" path. Only affects policy evaluation; the
   * branch must still physically exist on Neon (`pushConfig` never creates one).
   */
  branchExists?: boolean;
  /**
   * Auto-confirm overriding existing remote settings.
   *
   * When `true`, mutable drift on the selected branch (TTL, `protected` flag, compute
   * settings) is applied as actual mutations and the override-confirm prompt is
   * skipped. When `false` (default) the behaviour depends on whether `confirm` is
   * supplied:
   *   - With `confirm`: the callback is asked whether to apply the override.
   *   - Without `confirm`: drift is reported as a `PushConflictError` (legacy
   *     non-interactive default — preserved so programmatic SDK callers don't
   *     silently start mutating remote state).
   */
  updateExisting?: boolean;
  /**
   * Auto-confirm pushing to a protected branch.
   *
   * When `true`, no protected-branch confirmation is asked. When `false` (default):
   *   - With `confirm`: the callback is asked.
   *   - Without `confirm`: the push proceeds (legacy SDK default).
   */
  allowProtectedBranch?: boolean;
  /**
   * Optional confirmation callback. Invoked once with a single context object before
   * any mutations run when the push needs confirmation: pushing to a protected
   * branch (unless `allowProtectedBranch` is `true`) and/or applying mutable drift
   * (unless `updateExisting` is `true`).
   *
   * Both prompts collapse into a single callback invocation when both apply, so the
   * CLI can render one combined "are you sure?" prompt.
   *
   * Resolves to `true` to proceed, `false` to abort with {@link PushAbortedError}.
   *
   * Never invoked on `dryRun`.
   */
  confirm?: (context: PushConfirmContext) => boolean | Promise<boolean>;
  /**
   * Custom bundler for function source. Defaults to {@link buildFunctionBundle}
   * (esbuild). Inject your own to deploy functions without this package pulling
   * esbuild's native binary into your build — see {@link FunctionBundler}.
   */
  bundleFunction?: FunctionBundler;
  /**
   * When `true`, compute the full plan against the live remote state but **do not
   * execute any mutations**. The resulting `PushResult.applied` array records every
   * change that *would* run on a real push (with the same action / identifier / details
   * shape, so the existing CLI summary formatter just works), and conflicts are
   * reported instead of thrown.
   *
   * Used by `plan(config, branchId)` and any caller that wants a "would this push do
   * something dangerous?" check before invoking `pushConfig` for real.
   */
  dryRun?: boolean;
}
/**
 * Context handed to a {@link PushConfigOptions.confirm} callback. Both flags can be
 * `true` simultaneously when the push targets a protected branch *and* would override
 * existing settings — render a single combined prompt covering both reasons.
 */
interface PushConfirmContext {
  /** Name of the target branch on Neon. */
  branchName: string;
  /**
   * `true` when the target branch has the `protected` flag on Neon and the caller
   * did not pass `allowProtectedBranch: true`.
   */
  protectedBranch: boolean;
  /**
   * `true` when the plan would override existing remote settings (TTL, `protected`
   * flag, compute settings on an existing endpoint) and the caller did not pass
   * `updateExisting: true`. Additive operations (enabling Neon Auth / Data API for
   * the first time) are **not** counted here — those are unambiguous and never
   * prompt.
   */
  overrideUpdates: boolean;
}
/**
 * Push a Neon branch policy to a specific project + branch.
 *
 * Filesystem- and env-agnostic: the caller supplies an already-validated `Config` object
 * (from `defineConfig` / `loadConfigFromFile`) and explicit `projectId` + `branch` in
 * `options`. `pushConfig` performs no `.neon` lookups and reads no `NEON_*` env vars except the API credential/host resolution documented on `apiKey`/`apiHost`.
 *
 * It will **not** create a project or branch — both must already exist on Neon.
 */
declare function pushConfig(config: Config, options: PushConfigOptions): Promise<PushResult>;
//#endregion
export { PushConfigOptions, PushConfirmContext, pushConfig };
//# sourceMappingURL=push-config.d.ts.map