import { i as DiagnosticsOptions } from "../diagnostics-mftUZI7c.mjs";

//#region src/core/formats.d.ts
/**
 * Maximum length of a string that will be compiled by `new RegExp(...)`.
 * Patterns that exceed this cap are rejected without compilation. A
 * pathological pattern (e.g. `(a+)+`) doesn't need to be long to hang,
 * but the cap is cheap defence and stops obviously hostile input before
 * it reaches the regex engine.
 */
declare const MAX_REGEX_PATTERN_LENGTH = 500;
/**
 * Map a JSON Schema string `format` to the matching HTML `<input type="…">`
 * value, or `undefined` when the format does not correspond to a date/time
 * input. Shared by the HTML and headless React renderers so a single
 * mapping table governs both pipelines.
 */
declare function dateInputType(format: string | undefined): string | undefined;
/**
 * A format validator: either a RegExp pattern or a predicate function.
 */
type FormatValidator = RegExp | ((value: string) => boolean);
/**
 * Recognised JSON Schema formats with their validation patterns.
 * Unknown formats emit an `unknown-format` diagnostic and skip derivation.
 *
 * Draft origin reference — formats first standardised by each draft:
 *
 * - Draft 04: `date-time`, `email`, `hostname`, `ipv4`, `ipv6`, `uri`
 * - Draft 06: `uri-reference`, `uri-template`, `json-pointer`
 * - Draft 07: `date`, `time`, `idn-email`, `idn-hostname`, `iri`,
 *   `iri-reference`, `regex`, `relative-json-pointer`
 * - Draft 2019-09: `duration`, `uuid`
 * - Vocabulary extensions / non-standard: `binary` (OpenAPI), and the
 *   Zod-emitted formats `cuid`, `cuid2`, `nanoid`, `cidrv4`, `cidrv6`,
 *   `base64`, `base64url`, `e164`, `emoji`, `ulid`, `xid`, `ksuid`,
 *   `lowercase`, `uppercase`, `jwt`, `json-string`
 *
 * Policy: schema-components accepts ALL formats in ALL drafts. We do
 * not reject (e.g.) `uri-reference` on a Draft 04 schema or `uuid` on
 * a Draft 06 schema, even though the spec did not standardise those
 * names until a later draft. This matches the behaviour of every
 * mainstream JSON Schema validator (Ajv, jsonschema, etc.) and avoids
 * spurious failures on legitimate real-world schemas that pre-date or
 * post-date the dialect they declare. Authors who want strict draft-
 * locked behaviour should validate with a dedicated meta-schema tool.
 */
/**
 * Email format pattern, exported as a named const so callers that need a
 * guaranteed `RegExp` (rather than the `RegExp | undefined` shape of
 * `FORMAT_PATTERNS[name]` under `noUncheckedIndexedAccess`) can import it
 * directly. Used by the URI safety helpers for mailto address checks.
 */
declare const EMAIL_FORMAT_PATTERN: RegExp;
/**
 * Map of recognised JSON Schema string `format` values to RegExp
 * patterns. Consumed by `extractStringConstraints` to derive a
 * client-side `formatPattern` for renderers, and by
 * {@link validateFormat} for runtime checks.
 */
declare const FORMAT_PATTERNS: Readonly<Record<string, RegExp>>;
/**
 * Validate a string value against format constraints.
 * Returns `true` when the value matches the format,
 * `false` when it does not, and `undefined` when the format
 * is not recognised (no validator available).
 *
 * `diagnostics` and `pointer` are forwarded to validators that can
 * surface structured diagnostics — currently the `regex` format, which
 * emits `pattern-invalid` for over-length or malformed input.
 */
declare function validateFormat(value: string, format: string, diagnostics?: DiagnosticsOptions, pointer?: string): boolean | undefined;
//#endregion
export { EMAIL_FORMAT_PATTERN, FORMAT_PATTERNS, FormatValidator, MAX_REGEX_PATTERN_LENGTH, dateInputType, validateFormat };