Improved Nullable field support and allOf inheritance#80
Conversation
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (2)
🚧 Files skipped from review as they are similar to previous changes (1)
📝 WalkthroughWalkthroughAdds a new OpenAPI 3.1 spec with nullable fields and allOf-composed errors, updates the Zod generator to merge/preserve required fields across allOf, integrates the spec into the example-generation pipeline, adds end-to-end and unit tests, and implements a fetch-based RecordsClientFetch with tests. ChangesNullable allOf schema generation and consumption
Estimated code review effort🎯 4 (Complex) | ⏱️ ~60 minutes Possibly related PRs
Suggested labels
Poem
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #80 +/- ##
==========================================
+ Coverage 97.31% 97.35% +0.03%
==========================================
Files 20 20
Lines 3130 3213 +83
==========================================
+ Hits 3046 3128 +82
- Misses 84 85 +1 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
There was a problem hiding this comment.
Actionable comments posted: 1
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
packages/zenko/src/core/schema-generator.ts (1)
700-737:⚠️ Potential issue | 🟠 Major | ⚡ Quick winPreserve nullable object unions by evaluating
typearrays first.At Line 700, schemas with
propertiesshort-circuit tobuildZodObject(...)before theArray.isArray(schema.type)path runs.
That makestype: ["object", "null"]generate a non-nullable object schema and dropsnull.Suggested fix
- // Check for object with properties (including those without explicit type) - if (schema.type === "object" || schema.properties || schema.allOf) { - return buildZodObject( - schema, - options, - nameMap, - schemaRegistry, - currentSchemaName, - allOfRequired - ) - } - if (Array.isArray(schema.type)) { if (schema.type.length === 0) return "z.unknown()" if (schema.type.length === 1) { return getZodTypeFromSchema( { ...schema, type: schema.type[0] }, options, nameMap, schemaRegistry, currentSchemaName, ownName, allOfRequired ) } const unionParts = schema.type.map((memberType: string) => getZodTypeFromSchema( { ...schema, type: memberType }, options, nameMap, schemaRegistry, currentSchemaName, ownName, allOfRequired ) ) return `z.union([${unionParts.join(", ")}])` } + + // Check for object with properties (including those without explicit type) + if (schema.type === "object" || schema.properties || schema.allOf) { + return buildZodObject( + schema, + options, + nameMap, + schemaRegistry, + currentSchemaName, + allOfRequired + ) + }🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@packages/zenko/src/core/schema-generator.ts` around lines 700 - 737, The current early return that calls buildZodObject when schema.type === "object" or schema.properties causes schemas with type arrays (e.g., type: ["object","null"]) to lose the nullable union; move the Array.isArray(schema.type) handling ahead of the object/properties check or add a guard so that if schema.type is an array you first resolve the union via getZodTypeFromSchema (the Array.isArray branch that builds unionParts) before falling back to buildZodObject; adjust logic in getZodTypeFromSchema to prefer the type-array branch so buildZodObject is only used for definitive object types (e.g., when schema.type === "object" or no type array present).
🧹 Nitpick comments (2)
packages/zenko/src/__tests__/nullable-allof-errors.test.ts (1)
1-7: ⚡ Quick winReorder imports to match the TypeScript import-order rule.
Built-in modules should come before third-party imports in this file.
Proposed fix
-import { describe, test, expect } from "bun:test" import * as fs from "fs" import * as path from "path" import { pathToFileURL } from "url" +import { describe, test, expect } from "bun:test" import { nullableAllOfErrorsYamlPath } from "`@zenko/specs`" import { parseYaml } from "../utils/yaml" import { generate, type OpenAPISpec } from "../zenko"As per coding guidelines, TypeScript imports must be ordered built-in
→ third-party → workspace → local modules.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@packages/zenko/src/__tests__/nullable-allof-errors.test.ts` around lines 1 - 7, Reorder the import statements to satisfy the TypeScript import-order rule: place built-in modules (fs, path, url's pathToFileURL) first, then third-party imports (bun:test), then workspace packages (e.g., `@zenko/specs` -> nullableAllOfErrorsYamlPath), and lastly local project imports (../utils/yaml -> parseYaml and ../zenko -> generate, OpenAPISpec); update the import block so symbols like describe, test, expect remain associated with bun:test and all other named imports remain unchanged while only changing their order.Source: Coding guidelines
packages/zenko/src/core/__tests__/schema-generator.test.ts (1)
584-612: ⚡ Quick winUse named snapshots for these generated-output assertions.
These new cases are validating rendered generator output; converting the assertion blocks to
toMatchSnapshot("<descriptive-name>")would align with the test guideline and reduce brittle string-fragment checks.As per coding guidelines,
packages/zenko/src/**/*.test.{ts,tsx}should “Use snapshot testing withexpect(result).toMatchSnapshot()for output verification.”Also applies to: 714-806
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@packages/zenko/src/core/__tests__/schema-generator.test.ts` around lines 584 - 612, Replace the brittle string equality assertions in the tests that call getZodTypeFromSchema(...) with named snapshot assertions: for each test case (e.g., OpenAPI 3.1 nullable string/number/integer, single-element type array, empty type array) replace expect(...).toBe("...") with expect(getZodTypeFromSchema(...)).toMatchSnapshot("<descriptive-name>") using a clear descriptive snapshot name (e.g., "nullable-string-union", "nullable-integer-union", "nullable-number-union", "single-element-string-type", "empty-type-array"); ensure each test uses a distinct snapshot name so the snapshots are stored and compared instead of hard-coded string fragments and update any similar blocks later in the file (around the other cases referenced) to the same pattern.Source: Coding guidelines
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@packages/examples/src/records-client-fetch.ts`:
- Around line 35-41: The code currently always parses non-OK responses with
ListRecordsError; change each handler to validate against the endpoint-specific
error schema instead (e.g., in the listRecords flow keep ListRecordsError, in
getRecord use GetRecordError, in updateRecordStatus use
UpdateRecordStatusError), by replacing the generic parse call
(ListRecordsError.safeParse) with the appropriate schema.safeParse for the
function handling the response, and fall back to the generic HTTP Error
(`response.status`/`response.statusText`) only if the endpoint-specific parse
fails; apply the same fix to the other non-OK response blocks in this file (the
block around lines 48-67).
---
Outside diff comments:
In `@packages/zenko/src/core/schema-generator.ts`:
- Around line 700-737: The current early return that calls buildZodObject when
schema.type === "object" or schema.properties causes schemas with type arrays
(e.g., type: ["object","null"]) to lose the nullable union; move the
Array.isArray(schema.type) handling ahead of the object/properties check or add
a guard so that if schema.type is an array you first resolve the union via
getZodTypeFromSchema (the Array.isArray branch that builds unionParts) before
falling back to buildZodObject; adjust logic in getZodTypeFromSchema to prefer
the type-array branch so buildZodObject is only used for definitive object types
(e.g., when schema.type === "object" or no type array present).
---
Nitpick comments:
In `@packages/zenko/src/__tests__/nullable-allof-errors.test.ts`:
- Around line 1-7: Reorder the import statements to satisfy the TypeScript
import-order rule: place built-in modules (fs, path, url's pathToFileURL) first,
then third-party imports (bun:test), then workspace packages (e.g., `@zenko/specs`
-> nullableAllOfErrorsYamlPath), and lastly local project imports (../utils/yaml
-> parseYaml and ../zenko -> generate, OpenAPISpec); update the import block so
symbols like describe, test, expect remain associated with bun:test and all
other named imports remain unchanged while only changing their order.
In `@packages/zenko/src/core/__tests__/schema-generator.test.ts`:
- Around line 584-612: Replace the brittle string equality assertions in the
tests that call getZodTypeFromSchema(...) with named snapshot assertions: for
each test case (e.g., OpenAPI 3.1 nullable string/number/integer, single-element
type array, empty type array) replace expect(...).toBe("...") with
expect(getZodTypeFromSchema(...)).toMatchSnapshot("<descriptive-name>") using a
clear descriptive snapshot name (e.g., "nullable-string-union",
"nullable-integer-union", "nullable-number-union", "single-element-string-type",
"empty-type-array"); ensure each test uses a distinct snapshot name so the
snapshots are stored and compared instead of hard-coded string fragments and
update any similar blocks later in the file (around the other cases referenced)
to the same pattern.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: a3f2acdf-6482-46a2-85d1-e63f154b65a0
⛔ Files ignored due to path filters (1)
packages/zenko/src/__tests__/__snapshots__/nullable-allof-errors.test.ts.snapis excluded by!**/*.snap
📒 Files selected for processing (8)
packages/examples/generate.jspackages/examples/src/__tests__/records-client-fetch.test.tspackages/examples/src/records-client-fetch.tspackages/specs/index.tspackages/specs/resources/nullable-allof-errors.yamlpackages/zenko/src/__tests__/nullable-allof-errors.test.tspackages/zenko/src/core/__tests__/schema-generator.test.tspackages/zenko/src/core/schema-generator.ts
Summary by CodeRabbit
New Features
Bug Fixes
Tests