v2.13.0

What's Changed

New Features 🎉

• Introduce same effectType by @samchungy in #217

  This library now has a new effectType when dealing with Zod Effects. In most scenarios, our users were using transform to sanitise or transform while ensuring the type did not change, however, this library could not handle this.

  The new same option allows this library to pick the input Zod Type to produce a schema while ensuring that the input and output remain the same type.

  For example: when creating a response (output) schema for the following type this library cannot hook into the TypeScript
  compiler at runtime to understand that you wanted a string schema generated:

  z.string().transform((string) => string.toUpperCase());

  which meant that you had to declare the following in order to get it to work:

  z.string().transform((string) => string.toUpperCase()).openapi({ effectType: 'input' });
  
  // or
  
  z.string().transform((string) => string.toUpperCase()).pipe(z.string());

  However, in the first example this could be dangerous if a user was to change the transform to no longer be the same type:

  z.string().transform((string) => string.length).openapi({ effectType: 'input' });

  The new same type allows us to avoid this mistake:

  ✅ z.string().transform((string) => string.toUpperCase()).openapi({ effectType: 'same' });
  
  // Type '"same"' is not assignable to type 'CreationType | undefined'. ts(2322)
  ❌ z.string().transform((string) => string.length).openapi({ effectType: 'same' });

• Refactor Effect Handling by @samchungy in #211, #214

  This library now validates that effects used within registered Lazy schemas are not included in both input and output schemas. This could possibly be a breaking change if you were accidentally doing this.

  This library should also provide clearer errors when using Zod Effects with registered components which should make it easier to deal with effects.

  Before:

  Error: {"_def":{"in":{"_def":{"checks":[],"typeName":"ZodString","coerce":false}},"out":{"_def":{"checks":[],"typeName":"ZodNumber","coerce":false}},"typeName":"ZodPipeline","openapi":{"description":"A name that describes the job","example":"Mid level developer"}}} at /job > post > request body > content > application/json > schema > property: title contains a transformation but is used in both an input and an output. This is likely a mistake. Set an `effectType`, wrap it in a ZodPipeline or assign it a manual type to resolve

  After:

  Error: The ZodPipeline at /job > post > request body > content > application/json > schema > property: title is used within a registered compoment schema (jobTitle) and contains an output transformation (ZodPipeline) defined at /job > get > responses > 200 > content > application/json > schema > property: title which is also used in an input schema.
  
  This may cause the schema to render incorrectly and is most likely a mistake. You can resolve this by:
  
  1. Setting an `effectType` on the transformation to `same` or `input` eg. `.openapi({type: 'same'})`
  2. Wrapping the transformation in a ZodPipeline
  3. Assigning a manual type to the transformation eg. `.openapi({type: 'string'})`
  4. Removing the transformation
  5. Deregistering the component containing the transformation

• Add default as an effect by @samchungy in #215, #216

  #175 added a change which would generate differences in the schema for input and outputs for a default schema. This may be a breaking change if you were using .default() in a registered schema which is referenced in both a request and response schema. As such, effectType can now also be used to change the rendered type.

Other Changes

• Fix ESM importing on Node.js by @jaens in #208
• Fix duplicate parameter component check by @jaens in #207
• Remove duplicate descriptions on referenced schemas by @samchungy in #212

New Contributors

• @jaens made their first contribution in #208

Full Changelog: v2.12.0...v2.13.0