import { ZodCompilerPluginOptions } from "./unplugin/types.js";
import { TransformSourceMap } from "./unplugin/transform.js";
//#region src/turbopack.d.ts
/**
 * Plugin options minus the ones a loader host cannot express.
 *
 * Turbopack serializes loader options through `next.config`, so they have to be
 * plain JSON — hence no `apply` (a Vite lifecycle function) and a string-only
 * `schemaNamePattern` where the plugin also accepts a RegExp.
 *
 * No `cache` either: the disk cache's dependency bookkeeping leans on a
 * `buildEnd` flush that a loader has no equivalent for, and loader hosts keep
 * their own persistent result cache — Turbopack's is keyed on content plus the
 * dependencies declared below, which is what this would have re-implemented.
 *
 * No `parallel`: the concurrency is the host's to own. Turbopack already runs
 * loaders across its own worker pool, so a pool per loader invocation would
 * multiply threads against a machine that is already saturated — and the
 * module-cache staleness stamps below assume one shared execution cache.
 */
type ZodCompilerTurbopackOptions = Omit<ZodCompilerPluginOptions, "apply" | "cache" | "codegenMode" | "hoist" | "parallel"> & {
  hoist?: boolean | {
    schemaNamePattern?: string | null | undefined;
  } | undefined;
  /**
   * `"inline"` (default) emits the shared helpers into every transformed file.
   *
   * `"lean"` imports them from `zod-compiler/runtime` instead, so a bundle
   * carries one copy however many files were transformed. That specifier is a
   * real package subpath, which is what makes it usable from a loader at all —
   * the `virtual:` id the build plugins emit needs a `resolveId` hook, and a
   * loader has none.
   *
   * Opt-in rather than the default because it only holds when the host BUNDLES
   * the import. Next.js does for client and App Router server code, but Pages
   * Router server code externalizes node_modules imports unless
   * `bundlePagesRouterDependencies` is set — and `zod-compiler` is normally a
   * devDependency, so a production install prunes it and the route throws
   * ERR_MODULE_NOT_FOUND on the first request. A bigger bundle is the better
   * default than a runtime failure that no build step reports.
   * @default "inline"
   */
  codegenMode?: "lean" | "inline" | undefined;
};
/**
 * The slice of webpack's loader context this uses. Structural rather than
 * imported from webpack: the package must not take a webpack dependency to
 * serve a host that is not webpack.
 */
interface ZodCompilerLoaderContext {
  resourcePath: string;
  async(): (error: Error | null, code?: string, map?: TransformSourceMap) => void;
  getOptions?(): ZodCompilerTurbopackOptions | undefined;
  addDependency?(file: string): void;
  cacheable?(flag: boolean): void;
  query?: unknown;
}
declare function zodCompilerLoader(this: ZodCompilerLoaderContext, source: string, inputMap?: TransformSourceMap): void;
//#endregion
export { ZodCompilerLoaderContext, ZodCompilerTurbopackOptions, zodCompilerLoader as default };
//# sourceMappingURL=turbopack.d.ts.map