import type { App, ConfigVarUpdateOpts } from '@heroku/types/3.sdk'; import type { ResourceCtx } from '../../../core/extend-resource.js'; export type SetupStep = { kind: 'addon' | 'buildpack' | 'config-vars' | 'setup'; label?: string; }; export type CreateAndSetupOptions = { poller?: { onStart?: (step: SetupStep) => void; onStop?: (step?: SetupStep) => void; }; signal?: AbortSignal; }; export type CreateAndSetupInput = { addons?: Array<{ as?: string; plan: string; }>; buildpack?: string; configVars?: ConfigVarUpdateOpts; name?: string; region?: string; space?: string; stack?: string; team?: string; }; /** * Create an app and run its post-create setup in one call. * * Creates the app (team/space → `teamApp.create`, otherwise `app.create`), * then fans out the optional setup steps in parallel: add-ons * (`addOn.create` per plan), config vars (`configVar.update`), and buildpack * (`buildpackInstallation.update`). Returns the created `App`. * * Progress is reported via the `poller` convention. Because the steps run in * parallel and a caller's progress indicator is typically a single global * spinner, this method fires a single `onStart`/`onStop` pair around the whole * setup batch rather than one per step, so parallel steps don't clobber the * spinner. Per the poller contract, `onStart` fires BEFORE any request is * dispatched, and `onStop` fires ONLY on success — if a step rejects, the * error propagates and `onStop` is never called (there is no try/finally, so * the caller's error path stops the spinner). Signal threading binds the * signal to a scoped client (via `withSignal`) so an abort cancels in-flight * requests, not just the pre-flight `throwIfAborted()`. * * The CLI parses flags / heroku.yml into `input` and owns git-remote setup * and rendering; this method owns the API orchestration only. */ export declare function createAndSetup(ctx: Pick, input: CreateAndSetupInput, options?: CreateAndSetupOptions): Promise;