import * as RMOAS from '../rmoas.types';
type PrevSchemasType = RMOAS.SchemaObject[];
export interface toJSONSchemaOptions {
    /**
     * Whether or not to extend descriptions with a list of any present enums.
     */
    addEnumsToDescriptions?: boolean;
    /**
     * Current location within the schema -- this is a JSON pointer.
     */
    currentLocation?: string;
    /**
     * Object containing a global set of defaults that we should apply to schemas that match it.
     */
    globalDefaults?: Record<string, unknown>;
    /**
     * Is this schema the child of a polymorphic `allOf` schema?
     */
    isPolymorphicAllOfChild?: boolean;
    /**
     * Array of parent schemas to utilize when attempting to path together examples.
     */
    prevSchemas?: PrevSchemasType;
    /**
     * A function that's called anytime a (circular) `$ref` is found.
     */
    refLogger?: (ref: string, type: 'ref' | 'discriminator') => void;
    /**
     * A function that's called to potentially transform any discovered schema.
     */
    transformer?: (schema: RMOAS.SchemaObject) => RMOAS.SchemaObject;
}
export declare function getSchemaVersionString(schema: RMOAS.SchemaObject, api: RMOAS.OASDocument): string;
export declare function isPrimitive(val: unknown): boolean;
/**
 * Given an OpenAPI-flavored JSON Schema, make an effort to modify it so it's shaped more towards
 * stock JSON Schema.
 *
 * Why do this?
 *
 *  1. OpenAPI 3.0.x supports its own flavor of JSON Schema that isn't fully compatible with most
 *    JSON Schema tooling (like `@readme/oas-form` or `@rjsf/core`).
 *  2. While validating an OpenAPI definition will prevent corrupted or improper schemas from
 *    occuring, we have a lot of legacy schemas in ReadMe that were ingested before we had proper
 *    validation in place, and as a result have some API definitions that will not pass validation
 *    right now. In addition to reshaping OAS-JSON Schema into JSON Schema this library will also
 *    fix these improper schemas: things like `type: object` having `items` instead of `properties`,
 *    or `type: array` missing `items`.
 *  3. To ease the burden of polymorphic handling on our form rendering engine we make an attempt
 *    to merge `allOf` schemas here.
 *  4. Additionally due to OpenAPI 3.0.x not supporting JSON Schema, in order to support the
 *    `example` keyword that OAS supports, we need to do some work in here to remap it into
 *    `examples`. However, since all we care about in respect to examples for usage within
 *    `@readme/oas-form`, we're only retaining primitives. This *slightly* deviates from JSON
 *    Schema in that JSON Schema allows for any schema to be an example, but since
 *    `@readme/oas-form` can only actually **render** primitives, that's what we're retaining.
 *  5. Though OpenAPI 3.1 does support full JSON Schema, this library should be able to handle it
 *    without any problems.
 *
 * And why use this over `@openapi-contrib/openapi-schema-to-json-schema`? Fortunately and
 * unfortunately we've got a lot of API definitions in our database that aren't currently valid so
 * we need to have a lot of bespoke handling for odd quirks, typos, and missing declarations that
 * might be present.
 *
 * @todo add support for `schema: false` and `not` cases.
 * @see {@link https://json-schema.org/draft/2019-09/json-schema-validation.html}
 * @see {@link https://github.com/OAI/OpenAPI-Specification/blob/main/versions/3.0.3.md#schemaObject}
 * @see {@link https://github.com/OAI/OpenAPI-Specification/blob/main/versions/3.1.0.md#schemaObject}
 * @param data OpenAPI Schema Object to convert to pure JSON Schema.
 */
export default function toJSONSchema(data: RMOAS.SchemaObject | boolean, opts?: toJSONSchemaOptions): RMOAS.SchemaObject;
export {};
