import { NativeTraceDeps } from "./native-packages.js";
import { ResolvedFunctionConfig } from "@neon/config";

//#region src/lib/function-bundle.d.ts

/**
 * Builds the deployable ZIP bundle for a single function. The default
 * implementation ({@link buildFunctionBundle}) shells out to esbuild, but
 * `pushConfig` / `apply` accept a custom bundler so a consumer that can't ship
 * esbuild's native binary (e.g. a single-file CLI) can supply its own — a WASM
 * build, an esbuild binary on PATH, etc. — without this package dragging esbuild
 * into their bundle.
 */
type FunctionBundler = (fn: ResolvedFunctionConfig) => Promise<Uint8Array>;
/**
 * Prepended to the ESM bundle. Bundled dependencies are frequently CommonJS, but an ESM
 * output (`format: "esm"`) has no `require` / `__filename` / `__dirname` in scope — so any
 * bundled CJS code that calls `require(...)` would fail at load with
 * `Dynamic require of "x" is not supported`. Re-create those globals via `createRequire`
 * so CJS and ESM dependencies coexist in the single `index.mjs`.
 */
declare const ESM_CJS_INTEROP_BANNER = "import{createRequire as ___cr}from'module';import{fileURLToPath as ___f}from'url';import{dirname as ___d}from'path';const require=___cr(import.meta.url);const __filename=___f(import.meta.url);const __dirname=___d(__filename);";
/**
 * Build the deployable bundle (a ZIP archive of the esbuild-bundled source) for a function.
 *
 * This is the **imperative shell** step of function deploys, and the reason it lives in
 * `@neon/config-runtime` rather than `@neon/config`: it pulls in `esbuild`
 * (a native binary) and `fflate`. Keeping it out of `@neon/config` means a `neon.ts`
 * that only imports `defineConfig` never drags esbuild into the user's dependency tree or
 * bundle. Deploy-side consumers (the neonctl CLI, CI) import this package and get esbuild as
 * a normal, auto-installed dependency.
 *
 * esbuild and fflate are loaded with a dynamic `import()` (not a static top-level import) so
 * that nothing in this package's static graph names esbuild until a deploy actually runs —
 * a second layer of protection on top of the package split.
 *
 * Mirrors: `esbuild <source> --bundle --outfile=index.mjs --minify --format=esm
 * --platform=node --banner:js=<createRequire shim>`, then zips the emitted files into the
 * archive the Functions deploy endpoint expects. Dependencies are bundled into the entry
 * (Node built-ins stay external); see {@link ESM_CJS_INTEROP_BANNER} for why the banner.
 *
 * No source map is emitted: the Functions runtime does not run Node with source-map support,
 * so an uploaded `index.mjs.map` is never consumed (a thrown error's stack still points into
 * the minified bundle). Generating it only inflated the deployed archive, so it is omitted.
 */
declare function buildFunctionBundle(fn: ResolvedFunctionConfig, options?: {
  nativeDeps?: Partial<NativeTraceDeps>;
  /**
   * Where advisory findings go — the undeclared-native-dependency report, and a package
   * whose version could not be pinned.
   *
   * Defaults to discarding them, because a library has no business writing to the
   * console. Pass a handler: these are the only signal that a function will fail at
   * invoke, and the CLI wires this to its logger for exactly that reason.
   */
  onWarning?: (message: string) => void;
}): Promise<Uint8Array>;
//#endregion
export { ESM_CJS_INTEROP_BANNER, FunctionBundler, buildFunctionBundle };
//# sourceMappingURL=function-bundle.d.ts.map