[dinwwwh]

Requested by dinwwwh · project thread

Zod writes z.union([z.string(), z.number()]).nullable() as { "type": ["string", "number", "null"] }. In 3.0 that became:

{ "anyOf": [{ "type": "string", "nullable": true }, { "type": "number", "nullable": true }] }

openapi-generator, openapi-zod-client and datamodel-codegen ignore nullable inside an anyOf branch, so the generated types lost null. Now the branches leave nullable out and null gets its own branch, in the shape type: "null" already uses (#72):

{
  "anyOf": [
    { "type": "string" },
    { "type": "number" },
    { "type": "string", "nullable": true, "enum": [null] }
  ]
}

A small onlyNull() helper writes that shape for both this branch and finishSchema's null-only block. The test and the README row for type with several types are updated.

---

Generated by Claude Code

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

[macroscopeapp]

Approvability

Verdict: Approved at 6aa31a8

Macroscope's review found this PR approvable — This focused downgrader fix preserves nullability by emitting a dedicated null branch instead of relying on nullable inside other anyOf branches. Its runtime scope is limited to multi-type schemas containing null, with aligned documentation and regression coverage.

^{You can add or adjust custom eligibility rules. Learn more.}

[codspeed]

Merging this PR will not alter performance

✅ 21 untouched benchmarks

---

_{Comparing claude/project-thread-ypzah5 (6aa31a8) with main (a5d6ca6)}

[pullfrog]

✅ No new issues found.

Reviewed changes

• Null gets its own anyOf branch for multi-type schemas — convertType now drops nullable from each type branch and appends onlyNull() ({ type: 'string', nullable: true, enum: [null] }) when the type array contains "null", so generators that ignore nullable inside an anyOf branch keep null.
• onlyNull() helper extracted — shared by the new branch and finishSchema's null-only block; the block's delete out.enum; Object.assign(out, onlyNull()) preserves the previous key order (type, nullable, enum).
• Test and README updated — the ['array','string','null'] expectation now asserts the 3-branch shape, and the "several types" README row documents the null branch.

The reshaping is semantically equivalent to the prior output (both accept rest ∪ {null}), so there is no behavior regression. I ran the downgrader suite (197 passed, no snapshot churn) and uncheck over the changed files (oxlint, oxfmt, tsc all pass).

  ^{｜ View workflow run ｜ Using deepseek-v4.1-flash (free via Pullfrog for OSS) ｜ 𝕏}