There isn't a straightforward method within the library to achieve this specific task, but by delving into their private fields denoted with _, you can access the desired functionality.

However, it is important to note that this approach comes with certain risks as library developers typically do not assure stability of these private properties. If your code depends on this behavior, caution should be exercised particularly when updating versions.

Setting aside the disclaimer, the potential for something like this exists. The expansion of this concept to encompass more types is left as a challenge for the individual:

import { z } from "zod";

const schema = z.object({
  name: z.string(),
  age: z.number().nullable()
});

const schemaDefaults = <Schema extends z.ZodFirstPartySchemaTypes>(
  schema: Schema
): z.TypeOf<Schema> => {
  switch (schema._def.typeName) {
    case z.ZodFirstPartyTypeKind.ZodDefault:
      return schema._def.defaultValue();
    case z.ZodFirstPartyTypeKind.ZodObject: {
      // Although the switch statement may not have deduced this, the cast seems secure.
      return Object.fromEntries(
        Object.entries(
          (schema as z.SomeZodObject).shape
        ).map(([key, value]) => [key, schemaDefaults(value)])
      );
    }
    case z.ZodFirstPartyTypeKind.ZodString:
      return "";
    case z.ZodFirstPartyTypeKind.ZodNull:
      return null;
    case z.ZodFirstPartyTypeKind.ZodNullable:
      return null;
    // etc
    default:
      throw new Error(`Unsupported type ${schema._type}`);
  }
};

console.log(schemaDefaults(schema));

In this scenario, no defaults have been specified, yet the code still yields the expected output. For instance, if "foo" was designated as the default for name, the result would be

{ name: "foo", age: null }

An alternate, more concise approach could involve exploring one layer deep into the _def of your schema in search of functions like defaultValue to invoke. However, the provided method is deemed superior due to its potential to accommodate all fundamental zod schema types.

To conclude, it is worth mentioning that some zod types pose greater challenges than others. While assigning a default value of 0 to z.number may seem reasonable, handling cases involving z.union or z.intersection presents complex recursive scenarios.

Perhaps creating a dedicated library specifically for this purpose or submitting a feature request to incorporate it into the official API could prove beneficial.

After revisiting this discussion multiple times, I feel it's time to share my perspective:

The issue at hand for me has been about safely creating a new zod object while utilizing the defaults and also requiring non-default inputs.

My dilemma lies in how to effectively use the .parse function which only accepts unknown, making it challenging to discern between required and default values.

If you're facing a similar challenge and seeking something like MyZodObject.createInstance, I may have a straightforward solution.

This solution involves using z.input<typeof MyShape>.

Essentially, this method provides the expected TypeScript type with all necessary keys marked as required while allowing the rest to be filled in by the .default as optional.

For example:

const Model = z.object({
    title: z.string(),
    active: z.boolean().default(false)
})

type ModelOutput = z.infer<typeof Model>
// ^ type ModelOutput = {
//    title: string;
//    active: boolean;
//}

type ModelInput = z.input<typeof Model>
// ^ type ModelInput = {
//    title: string;
//    active?: boolean | undefined; // << DEFAULT
// }

A Simple Method to Instantiate Zod Objects Safely with Default Values

const makeInstantiator =
  <T extends z.ZodType<any>>(model: T) =>
  (input: z.input<T>): z.output<T> => {
    return model.parse(input);
  };

const instantiateModel = makeInstantiator(Model);
// const instantiateModel: (input: {
//   title: string;
//   active?: boolean | undefined;
// }) => {
//   title: string;
//   active: boolean;
// }

Important: After attempting the accepted answer (.parse({})), I encountered issues with using default values that did not meet validation criteria, leading to errors. Additionally, I faced challenges with nested schema fields.

In my exploration, I devised a solution similar to an earlier suggestion. While some typing may be suboptimal (particularly in areas like (fieldSchema._def as ...)), it successfully resolved my linting concerns.

The method outlined below aims to construct a "default" object based on a provided Zod schema, adhering to the following hierarchy and effectively handling nested schema fields (z.object(..)):

• If a default value is specified for a field (z..default(..)), it is returned immediately
• If no default value is set & it's a "base" Zod schema field (e.g., z.number(), z.string(), etc.), a corresponding "base" default is retrieved from a designated object (BASE_DEFAULTS)
• If no default value is set & it's a "transformed" Zod schema field (e.g., z.refine(..), z.coerce(..), etc.), an attempt is made to determine the "inner type" (

  z.ZodTransformationType<z.ZodInnerTypeIsLocatedHere?, ...>

  )
  • This specific scenario hasn't been extensively tested; my approach involves consistently providing defaults to avoid dealing with transformed types

// Code block remains unchanged

Please note that I've primarily utilized this method for generating default values in react-hook-form implementation. The provided BASE_DEFAULTS_FORM differs from standard defaults due to form compatibility requirements (e.g., converting numbers to strings within forms for enhanced usability).

// Code block remains unchanged

Given imperfect typing, certain sections require typecasting. Suggestions for enhancing typing accuracy are welcome!

// Code block remains unchanged