@traversable/schema
    Preparing search index...

    Function deepNonLoose

    • Converts an arbitrary zod schema into its "deeply-non-loose" form.

      That just means that the schema will be traversed, and all z.looseObject z.looseObject schemas will be rewritten as z.object z.object schemas.

      Type Parameters

      • T extends
            | $ZodType<unknown, unknown, $ZodTypeInternals<unknown, unknown>>
            | ZodType<unknown, unknown, $ZodTypeInternals<unknown, unknown>>

      Parameters

      • type: T

      Returns T

      import * as vi from "vitest"
      import { z } from "zod"
      import { zx } from "@traversable/zod"

      // Using `zx.deepNonLoose.writeable` here to make it easier to visualize `zx.deepNonLoose`'s behavior:
      vi.expect.soft(zx.deepNonLoose.writeable(
      z.looseObject({
      a: z.number(),
      b: z.nullable(z.string()),
      c: z.looseObject({
      d: z.array(
      z.looseObject({
      e: z.number().max(1),
      f: z.boolean()
      })
      ).length(10)
      })
      })
      )).toMatchInlineSnapshot
      (`
      "z.object({
      a: z.number(),
      b: z.string().nullable(),
      c: z.object({
      d: z.array(
      z.object({
      e: z.number().max(1),
      f: z.boolean()
      })
      ).length(10)
      })
      })"
      `)
    Index

    Properties

    Properties

    writeable: (
        ...a: [
            type: | $ZodType<unknown, unknown, $ZodTypeInternals<unknown, unknown>>
            | ZodType<unknown, unknown, $ZodTypeInternals<unknown, unknown>>,
        ],
    ) => string

    Convenience function that composes zx.deepNonLoose and zx.toString.

    This option is useful when you have particularly large schemas, and are starting to feel the TS compiler drag. With zx.deepNonLoose.writeable, you can pay that price one by writing the new schema to disc.

    Keep in mind that the most expensive part of the transformation is at the type-level; writing to disc solves that problem, but introduces a syncing problem, so if you don't "own" the schema, make sure you've at least thought about what you'll do when the schema inevitably changes.