Skip to content

Releases: asteasolutions/zod-to-openapi

v4.3.0

20 Feb 11:05
Compare
Choose a tag to compare

What's Changed

  • Added discriminator mapping for objects using enums as discriminator

Full Changelog: v4.2.0...v4.3.0

v4.2.0

13 Feb 18:55
Compare
Choose a tag to compare

What's Changed

  • 'ZodNativeEnum' would be generated as type: 'integer' instead of type: 'number'

Full Changelog: v4.1.0...v4.2.0

v4.1.0

10 Jan 10:32
Compare
Choose a tag to compare

What's Changed

  • updated all jest related dependencies in order to update json5 and thus resolving a security vulnerability
  • #80 allow zod objects to be used to define route headers

Full Changelog: v4.0.0...v4.1.0

v4.0.0

20 Dec 12:14
Compare
Choose a tag to compare

What's Changed

Zod introduced a breaking change to one of its models in its latest version. See this comment

Because of that we are updating our peer dependency to ^3.20.2.

Full Changelog: v3.4.0...v4.0.0

v3.4.0

15 Dec 14:19
Compare
Choose a tag to compare

What's Changed

  • Added ZodString Datetime support

Full Changelog: v3.3.0...v3.4.0

v3.3.0

05 Dec 21:22
Compare
Choose a tag to compare

What's Changed

  • Fixed exclusive minimum and maximum checks for numbers

Examples

The following schema z.number().gt(0) would have the following result

{ type: 'number', minimum: 0, exclusiveMinimum: true } // for OpenApi 3.0.0
{ type: 'number', exclusiveMinimum: 0 } // for OpenApi 3.1.0 and higher

Similarly, for the schema z.number().lt(10) the result would be

{ type: 'number', maximum: 10, exclusiveMaximum: true } // for OpenApi 3.0.0
{ type: 'number', exclusiveMaximum: 10 } // for OpenApi 3.1.0 and higher

Full Changelog: v3.2.0...v3.3.0

v3.2.0

04 Dec 08:22
Compare
Choose a tag to compare

What's Changed

  • added support for branded types [closes #72]

Full Changelog: v3.1.0...v3.2.0

v3.1.0

22 Nov 08:59
Compare
Choose a tag to compare

What's Changed

  • Added additionalProperties: false to strict objects. Removed additionalProperties: true from regular objects since this is the OpenApi default
  • Fix referencing schema with unrecognized type

Full Changelog: v3.0.1...v3.1.0

v3.0.1

21 Nov 09:51
Compare
Choose a tag to compare

What's Changed

  • Fixed a Typescript 4.9
  • Fixed Route types to support strict objects

Full Changelog: v3.0.0...v3.0.1

v3.0.0

07 Nov 21:09
Compare
Choose a tag to compare

Summary

  • Added support for Open API 3.1.0
  • Add typing for examples and default metadata
  • Added discriminator key to ZodDiscriminatedUnion schemas
  • Added support for ZodDate type
  • Added support for object inheritance when it's more than one level deep
  • Added support for default
  • Added support for minLength/maxLength on string type
  • Exposed a function getOpenApiMetadata that exposes all provided metada

Full Changelog: v2.3.0...v3.0.0

Migrating to v3.0.0

The v3.0.0 release comes out with support for OpenApi v3.1.0. This new version comes with some breaking changes around null values. Check the OpenApi changelog for more information.

How it affects @asteasolutions/zod-to-openapi

Schema generation

The generator constructor now takes 2 arguments - the second one being the version OpenApi target version. This version would be used when generating the schemas provided as the first argument.

So if you had something like this:

const generator = new OpenAPIGenerator(registry.definitions);

it should become:

const generator = new OpenAPIGenerator(registry.definitions, '3.0.0'); // Where 3.0.0 can be replaced with your desired version

Additionally the openapi version used to be passed in the config object of generateDocument. It should not be passed anymore since the version provided in the constructor is the one that would be used.

Types

We've updated our underlying library for OpenApi object types. As a result the .openapi method would not accept "random" keys that are not OpenApi specific. All additional keys must now follow the format x-{some-string}. This is expected since it better suites the OpenApi specification and if you used it with different keys it might have been incorrect to start with.

We've also separated the internal metadata provided to zod objects. That means that you cannot use .openapi to provide a refId or extendedFrom manually. That was never the intended behavior to start with. Those are meant for internal usage only and any changes to them might break the inner workings of the library.

Note: If for some reason you want to modify such properties manually, you can use the internal_openapi method added for every zod schema at your own risk.