Skip to content

v3.0.0

Compare
Choose a tag to compare
@AGalabov AGalabov released this 07 Nov 21:09
· 273 commits to master since this release

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.