chore(deps): update dependency @asteasolutions/zod-to-openapi to v8

[renovate]

This PR contains the following updates:

Package	Change	Age	Confidence
@asteasolutions/zod-to-openapi	^4.7.0 → ^8.4.3

---

Release Notes

asteasolutions/zod-to-openapi (@​asteasolutions/zod-to-openapi)

v8.4.3

Compare Source

What's Changed

• Bump rollup from 4.22.4 to 4.59.0

Full Changelog: asteasolutions/zod-to-openapi@v8.4.2...v8.4.3

v8.4.2

Compare Source

What's Changed

• Bump minimatch

Full Changelog: asteasolutions/zod-to-openapi@v8.4.1...v8.4.2

v8.4.1

Compare Source

What's Changed

• Fix memory leak in generateDocument() when using request parameters (fixes #​361)

Full Changelog: asteasolutions/zod-to-openapi@v8.4.0...v8.4.1

v8.4.0

Compare Source

What's Changed

• Added support for z.json (#​353)
• Added support for template literals (#​352)
• Fixed a bug in some nested structures when using isAnyZodType with null/undefined #​343
• Exported OpenApiOptions to resolve a problem when extending an object schema. For more information see: #​341

Full Changelog: asteasolutions/zod-to-openapi@v8.3.3...v8.4.0

v8.3.3

Compare Source

What's Changed

• use correct date-time instead of date when using z.date
• fix: add null option for nullable enum

Full Changelog: asteasolutions/zod-to-openapi@v8.3.2...v8.3.3

v8.3.2

Compare Source

Testing Trusted Publishers setup again

Full Changelog: asteasolutions/zod-to-openapi@v8.3.1...v8.3.2

v8.3.1

Compare Source

Testing the Trusted Publihsers setup

Full Changelog: asteasolutions/zod-to-openapi@v8.3.0...v8.3.1

v8.3.0

Compare Source

What's Changed

• 🎉 FINALLY added support for zod lazy (and recursive schemas with getters). Closes: #​247, #​300 and the discussion in #​191
• Bump js-yaml from 3.14.1 to 3.14.2
• Setup Trusted Publishsers for NPM

Full Changelog: asteasolutions/zod-to-openapi@v8.2.0...v8.3.0

v8.2.0

Compare Source

What's Changed

• (#​327 ) feat: support zodv4 prefault new type

Full Changelog: asteasolutions/zod-to-openapi@v8.1.0...v8.2.0

v8.1.0

Compare Source

What's Changed

• Improve Zod v4 type compatibility in module augmentation (fixes #​321 ) thanks to @​YeeP79
• Add option to sort schemas and parameters (fixes: #​312) See more details on how to use it here

Full Changelog: asteasolutions/zod-to-openapi@v8.0.0...v8.1.0

v8.0.0

Compare Source

Added Zod v4 support 🚀

Support for properties from .meta

With zod's new option for generating JSON schemas and maintaining registries we've added a pretty much seamless support for all metadata information coming from .meta calls as if that was metadata passed into .openapi.

So the following 2 schemas produce exactly the same results:

const schema = z
  .string()
  .openapi('Schema', { description: 'Name of the user', example: 'Test' });

const schema2 = z
  .string()
  .meta({ id: 'Schema2', description: 'Name of the user', example: 'Test' });

Removing extendZodWithOpenApi

This also means that unless you are using some of our more complicated scenarios you could even generate a schema without using extendZodWithOpenApi in your codebase and only rely on .meta to provide additional metadata information and schema names (using the id property).

Where would you still need to use extendZodWithOpenApi and .openapi

1. When extending registered schemas that are both registered and want the extended one to use anyOf i.e:

const schema = z.object({ name: z.string() }).openapi('Schema');

const schema2 = schema.extend({ age: z.number() }).openapi('Schema2'); // this one would have anyOf and a reference to the first one

2. Defining parameter metadata. So for example when doing:

registry.registerPath({
  // ...
  request: {
    query: z.object({
      name: z.string().openapi({
        description: 'Schema level description',
        param: { description: 'Param level description' }, 
      }),
    }),
  },
});

the result would be:

  "parameters": [
      {
        "schema": {
          "type": "string",
          "description": "Schema level description" // comes directly from description
        },
        "required": true,
        "description": "Param level description", // comes from param.description
        "name": "name",
        "in": "query"
      }
  ],

What's Changed as well

• Added support for required modifier (fixes #​305)*
• Added support for conditional oneOf instead of anyOf for unions (fixes #​236 and #​227). Read more about in the README
• Exposed a getRefId function (fixes #​319)

Full Changelog: asteasolutions/zod-to-openapi@v7.3.4...v8.0.0

v7.3.4

Compare Source

What's Changed

• check for missing _internal when extending a non registered schema by @​AGalabov in #​309 (fixes #​297 and #​276 )
• remove omit checks for null and leave only undefined by @​AGalabov in #​310 (fixes: #​283)

Full Changelog: asteasolutions/zod-to-openapi@v7.3.3...v7.3.4

v7.3.3

Compare Source

Full Changelog: asteasolutions/zod-to-openapi@v7.3.2...v7.3.3

Updated README.md

Updated README.md to point users to the 8.0.0-beta version for compatibility with zod v4

v7.3.2: - blank

Compare Source

No changes, but need this to be the latest version since we accidentally published a 7.3.1-beta-zod-v4-2.

Making this release so that people don't end up using the accidentally published one.

v7.3.0

Compare Source

What's Changed

• README changes
• Add isDate to string transformer
• Zod 3.23.8 upgrade
• #​274 allow refs to be passed to response configurations
• #​271 handle instance of and custom required fields

Full Changelog: asteasolutions/zod-to-openapi@v7.2.0...v7.3.0

v7.2.0

Compare Source

What's Changed

• #​256 added more string formats:
  • .emoji()
  • .cuid()
  • .cuid2()
  • .ulid()
  • .ip()

Full Changelog: asteasolutions/zod-to-openapi@v7.1.2...v7.2.0

v7.1.2

Compare Source

What's Changed

• Documentation: update to include information about strict usage on an object (diff)
• Bump rollup from 4.13.2 to 4.22.4 (diff)

Full Changelog: asteasolutions/zod-to-openapi@v7.1.1...v7.1.2

v7.1.1

Compare Source

What's Changed

• Bump braces from 3.0.2 to 3.0.3 by Dependabot #​241

Full Changelog: asteasolutions/zod-to-openapi@v7.1.0...v7.1.1

v7.1.0

Compare Source

What's Changed

• allow nested effects on parameters (#​238 )

Full Changelog: asteasolutions/zod-to-openapi@v7.0.0...v7.1.0

v7.0.0

Compare Source

What's Changed

• Added ESM modules export alongside the already present CJS (#​219)
• Added support for .refine() and .transform on ZodObjects in request query/params/headers/cookies (#​198)

BREAKING CHANGES ⚠️

❗ None of the changes that we've made are breaking in terms of code integration but their behavior (result) is changed:

Handle zod tuples with prefixItems for OpenAPI v3.1.0 (#​221 )

As of OpenAPI v3.1.0 there is a better representation of tuples - ordered items with the use of the prefixItems keyword. See more here

BigInt is now transformed as type string

z.bigint() // this is now transformed to `{ type: 'string', pattern: "^\d+$' }` instead of an `'integer'` type.

A BigInt can represent a number with a arbitrary size and that also means numbers that do not fall in the int64 format. As such for a library based on the JS world it is safer to represent a z.bigint() instance as a string containing only digits. In a real life scenario a BigInt instance can only be created from whatever was passed through HTTPS - and that can be both number and string as a basis.

Along with that the support for the minimum and maximum values have been removed.

Full Changelog: asteasolutions/zod-to-openapi@v6.4.0...v7.0.0

v6.4.0

Compare Source

What's Changed

• make examples use input type instead of output (same as what we sue to generate in the docs) (#​189)
• add autocompletion for common media types
• handle enums as keys for zod records (#​211)

Full Changelog: asteasolutions/zod-to-openapi@v6.3.1...v6.4.0

v6.3.1

Compare Source

What's Changed

• fixed deepPartial modifier preserving refId (#​200 )

Full Changelog: asteasolutions/zod-to-openapi@v6.3.0...v6.3.1

v6.3.0

Compare Source

What's Changed

• Bump @​babel/traverse from 7.20.12 to 7.23.2
• #​188 - do not label default schemas as required

Full Changelog: asteasolutions/zod-to-openapi@v6.2.0...v6.3.0

v6.2.0

Compare Source

What's Changed

• #​176 added support for z.bigint
• #​177 fix .describe for paramters not putting the description in the correct place

Full Changelog: asteasolutions/zod-to-openapi@v6.1.0...v6.2.0

v6.1.0

Compare Source

What's Changed

• #​173 Added support for ZodReadonly

Full Changelog: asteasolutions/zod-to-openapi@v6.0.0...v6.1.0

v6.0.0

Compare Source

What's Changed

• [BREAKING] Remove openapi3-ts exports since they break some applications but were never exported as a feature but rather for convenience. If they are needed one can simply add a dependency on openapi3-ts itslef

Full Changelog: asteasolutions/zod-to-openapi@v5.5.0...v6.0.0

v5.5.0

Compare Source

What's Changed

• Combine manually passed parameters from config.parameters with the generated ones from config.request

Full Changelog: asteasolutions/zod-to-openapi@v5.4.0...v5.5.0

v5.4.0

Compare Source

What's Changed

• Added support for cookies in RouteConfig.request object

Full Changelog: asteasolutions/zod-to-openapi@v5.3.1...v5.4.0

v5.3.1

Compare Source

What's Changed

• Fixed schemas not being generated for standard zod types when using a production build with minification / uglification being turned on (#​158)

Full Changelog: asteasolutions/zod-to-openapi@v5.3.0...v5.3.1

v5.3.0

Compare Source

What's Changed

• Provide proper type for default responses (fixes #​155)
• Added support for .catchall (#​154 )

Full Changelog: asteasolutions/zod-to-openapi@v5.2.0...v5.3.0

v5.2.0

Compare Source

What's Changed

• #​149 remove unnecessary nullables from schemas by @​AGalabov in #​152
• #​148 and #​153 Fixed error in README.mg - The correct imports are OpenApiGeneratorV3/OpenApiGeneratorV31 not OpenAPIGeneratorV3 and OpenAPIGeneratorV318

Full Changelog: asteasolutions/zod-to-openapi@v5.1.0...v5.2.0

v5.1.0

Compare Source

What's Changed

• handle null type based on openapi version (fixes #​139)
• fixed metadata not being preserved from .deepPartial (fixes #​132)
• improve handling of preprocess (#​143)
• fixed metadata not being preserved from .transform and .refine (fixes #​79)
• added support for z.any()

Full Changelog: asteasolutions/zod-to-openapi@v5.0.0...v5.1.0

v5.0.0

Compare Source

zod-to-openapi v5.0.0 is finally here 🎉

What's Changed

• Automatic registration of schemas through the .openapi method
• Introduced separate generators for different OpenAPI versions

Full Changelog: asteasolutions/zod-to-openapi@v4.8.0...v5.0.0

Migrating to v5.0.0

How to use the separated generators

Lets say you had something like this:

import { OpenAPIRegistry, OpenAPIGenerator } from '@​asteasolutions/zod-to-openapi';

const registry = new OpenAPIRegistry();
// Register definitions here

const generator = new OpenAPIGenerator(registry.definitions, '3.0.0');

generator.generateDocument({
    info: {},
    servers: [{ ... }],
  });

When migrating to v5.0.0 it would start to look like this:

// Change the import from OpenAPIGenerator to OpenAPIGeneratorV3
import { OpenAPIRegistry, OpenAPIGeneratorV3 } from '@​asteasolutions/zod-to-openapi';

const registry = new OpenAPIRegistry();
// Register definitions here

// Do not pass the specific OpenAPI version to the constructor - just definitions
const generator = new OpenAPIGeneratorV3(registry.definitions);

generator.generateDocument({
    // Pass the specific OpenAPI version here in the config instead. This would not influence the
    // behavior of the generator - it is just the `openapi` value to be returned in tour document.
    openapi: '3.0.0',
    info: {},
    servers: [{ ... }],
  });

And similarly if you were using the generator as:

const generator = new OpenAPIGenerator(registry.definitions, '3.1.0');

the respective change would be to start using:

const generator = new OpenAPIGeneratorV31(registry.definitions);

generator.generateDocument({ openapi: '3.1.0', ... })`

Taking advantage of the automatic registration and how to use it

Registering schemas has never been easier.

Let's say you had an example registered schema like

const schema = registry.register(
  'Schema',
  z.string().openapi({ description: 'Some string' })
);

This is still valid. However an alternative approach to writing this can now be used:

const schema = z.string().openapi('Schema', { description: 'Some string' });

Notice how there is no registry involved. And that is the idea. Thanks to this approach we can do the following:

const entrySchema = z
  .object({
    key: z.string().openapi('Key', { description: 'Some string' }),
    person: z.object({ name: z.string(), age: z.number() }).openapi('User'),
  })
  .openapi('UserEntry');

// and you can directly pass the schema to the generator if you want:
const generator = new OpenApiGeneratorV3([entrySchema]);
const generateDocument = generator.generateComponents();

This would produce the following result:

{
  "components": {
    "schemas": {
      "Key": { "type": "string", "description": "Some string" },
      "User": {
        "type": "object",
        "properties": {
          "name": { "type": "string" },
          "age": { "type": "number" }
        },
        "required": ["name", "age"]
      },
      "UserEntry": {
        "type": "object",
        "properties": {
          "key": { "$ref": "#/components/schemas/Key" },
          "person": { "$ref": "#/components/schemas/User" }
        },
        "required": ["key", "person"]
      }
    }
  }
}

The key part here is that in the example above we've only passed the entrySchema. However @asteasolutions/zod-to-openapi would generate and reference any schema that has an identifier (the first parameter of .openapi) - in the example above - Key and User.

Going one step further this would allow any user to not pass in zod schemas to the generator at all. You can only pass route definitions and @asteasolutions/zod-to-openapi would take care of all the referenced schemas on it's own:

For example, using the example above but changing the generator constructor we can have:

registry.registerPath({
  method: 'get',
  path: '/users',
  responses: {
    200: {
      description: 'User results',
      content: {
        'application/json': {
          schema: z.array(entrySchema),
        },
      },
    },
  },
});

// Notice how entrySchema is not passed at all
const generator = new OpenApiGeneratorV3(registry.definitions);
const generateDocument = generator.generateDocument({
  /* your document config here*/
});

This would produce the exact same result for component/schemas and the path would just look like this

"paths": {
    "/users": {
        "get": {
            "responses": {
                "200": {
                    "description": "Success",
                    "content": {
                        "application/json": {
                            "schema": {
                                "type": "array",
                                "items": {
                                    "$ref": "#/components/schemas/UserEntry"
                                }
                            }
                        }
                    }
                }
            }
        }
    }
}

---

Configuration

📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.

---

• If you want to rebase/retry this PR, check this box

---

This PR was generated by Mend Renovate. View the repository job log.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

1 Skipped Deployment

Project	Deployment	Actions	Updated (UTC)
jitaspace	Skipped		Mar 13, 2026 6:08pm

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud