fix(toJSONSchema): preserve default value through pipe/transform in input mode

[VihAMBR]

Problem

z.string().transform(s => s).default("hello") passed to z.toJSONSchema({ io: "input" }) silently drops the default keyword:

z.toJSONSchema(z.string().transform(s => s).default("hello"), { io: "input" })
// emits { type: "string" }  ← default: "hello" is lost

// without the transform it works correctly:
z.toJSONSchema(z.string().default("hello"), { io: "input" })
// { type: "string", default: "hello" }  ✓

Fixes #6049.

Root cause

process() in to-json-schema.ts runs isTransforming(schema) after every processor and unconditionally deletes result.schema.default when the check returns true. For a ZodDefault whose inner type is a ZodPipe containing a transform, isTransforming returns true — so the default value that defaultProcessor just set on the schema is immediately wiped.

The deletion was intended for cases where default is inherited from a pipe (output-side default), not for ZodDefault, which always declares an explicit input-side default.

Fix

Skip the delete result.schema.default step when def.type === "default". The ZodDefault processor always sets default intentionally; removing it here is wrong regardless of whether the inner type transforms.

// to-json-schema.ts
if (ctx.io === "input" && isTransforming(schema)) {
  delete result.schema.examples;
  // ZodDefault explicitly declares the input-side default — preserve it even through transforms
  if (def.type !== "default") {
    delete result.schema.default;
  }
}

Test changes

• Updated existing snapshot for a.default(1234) (type-changing transform): with this fix, default: 1234 now appears in the input schema. The default keyword in JSON Schema is advisory and does not need to validate against the schema type, so this is spec-compliant and more informative for tooling.
• Added a new test reproducing the exact case from v4: toJSONSchema drops default when the defaulted schema contains a transform/pipe #6049.

[pullfrog]

Reviewed changes — fixes z.toJSONSchema() dropping default when a ZodDefault wraps a pipeline containing a transform in io: "input" mode. The isTransforming check recurses into ZodDefault's inner type, so any transform inside caused process() to unconditionally wipe the default value that defaultProcessor just set. The fix guards the delete with def.type !== "default".

• Guard delete result.schema.default with def.type !== "default" in process() — ZodDefault always declares an explicit input-side default, so removing it here is wrong regardless of whether the inner type transforms. ZodPrefault already had equivalent protection at L211 via result.schema.default ??= result.schema._prefault.
• Add regression test for #6049 — covers both the reported z.string().transform(s => s).default("hello") case and the z.string().transform(...).pipe(z.string()).default("hello") variant.
• Update existing inline snapshot for a.default(1234) with a type-changing transform to reflect the now-correctly-preserved default: 1234.

✅ No new issues found.

  ^{｜ View workflow run ｜ Using DeepSeek Pro (free via Pullfrog for OSS) ｜ 𝕏}

[wahajahmed010]

A clean, well-documented fix. The root-cause analysis is excellent — isTransforming runs after every processor and the unconditional delete result.schema.default was colliding with defaultProcessor.

Logic: Correct. Checking def.type !== "default" is the right discriminant — only ZodDefault intentionally sets result.schema.default on the input side. One subtle edge case: if a future processor also sets default on input for a non-ZodDefault schema, this guard would not cover it. A snapshot approach ("was it set before?") would be more robust, but that is future-proofing, not a current bug.

Tests: Snapshot update and new #6049 repro test look correct. The pipe-through-transform test covering both sides is thorough.

Edge case: The static def.type check assumes ZodDefault def.type is always "default". From reading the Zod source — confirmed, it is. Safe.

Nice work — minimal, correct, well-explained.