Conversation
This comment was marked as resolved.
This comment was marked as resolved.
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 6
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/resources/anyof-combinations.yaml (1)
1-214: Address Checkov OpenAPI findings (security + maxItems) and tightenanyOfbranches.These look like CI blockers if Checkov scans test fixtures: add a security scheme + global security, and add
maxItemsto the array response. Also consider makingContact.anyOfbranches explicit object schemas for wider validator compatibility.Proposed YAML changes
openapi: 3.0.0 info: title: anyOf Combinations Test API version: 1.0.0 description: Tests anyOf for flexible schema matching and combinations +security: + - bearerAuth: [] + paths: /contacts: post: operationId: createContact @@ /search: get: @@ responses: "200": description: Search results content: application/json: schema: type: array + maxItems: 100 items: $ref: "#/components/schemas/SearchResult" components: + securitySchemes: + bearerAuth: + type: http + scheme: bearer schemas: @@ Contact: type: object required: - name anyOf: - - required: [email] - - required: [phone] + - type: object + required: [email] + - type: object + required: [phone] properties: name: type: string
🤖 Fix all issues with AI agents
In @packages/zenko/src/__tests__/additional-properties.test.ts:
- Around line 1-251: Many tests repeat reading and parsing
"src/resources/additional-properties.yaml"; extract that into a shared setup to
avoid duplication by creating a beforeAll (or helper) that reads fs.readFileSync
and calls parseYaml once and stores the parsed spec in a variable used by tests
(e.g., specYaml), then call generate(specYaml) inside each test; update tests
that create their own spec (like the "applies array bounds for top-level arrays"
test) to remain unchanged and ensure variables named specYaml and result
continue to be used so functions generate and parseYaml are referenced
consistently.
In @packages/zenko/src/__tests__/anyof-combinations.test.ts:
- Around line 127-138: The current test "handles anyOf in query parameters" only
asserts result contains "searchItems" which doesn't verify anyOf handling;
update the test to either assert the exact generated parameter
type/serialization emitted by generate(specYaml) for the searchItems operation
(e.g., check that the query parameter type string or function signature produced
for the filter parameter includes the expected union/anyOf representation) by
inspecting result for that specific type snippet, or replace the test body to
use a snapshot (expect(result).toMatchSnapshot()) so the full output is
validated; locate the test by its name and references to generate(specYaml),
specContent/"anyof-combinations.yaml", and result to implement the stronger
assertion or snapshot.
In @packages/zenko/src/__tests__/complex-composition.test.ts:
- Around line 76-108: These tests contain placeholder comments instead of
assertions; update the "handles anyOf inside allOf" and "handles nested oneOf
inside allOf" tests to either assert the intended semantics or remove them: for
the first test assert that generated output includes a union for metadata (e.g.,
contains a z.union or equivalent combining SimpleMetadata and ExtendedMetadata
alongside the exports Resource, SimpleMetadata, ExtendedMetadata), and for the
second test assert that ConfigurableItem combines base properties with a union
of BasicConfig and AdvancedConfig (check for z.union or the expected merged
schema representation in result in addition to the existing export checks);
apply the same change pattern to the other flagged test blocks (lines referenced
109-122, 139-152, 183-215) so no test is left as a TODO comment without concrete
assertions or is removed.
In @packages/zenko/src/__tests__/non-json-responses.test.ts:
- Around line 1-313: The tests repeat fs.readFileSync + parseYaml + generate in
many cases; extract that into a shared setup to remove duplication by adding a
beforeAll hook (or a helper function) that reads
"src/resources/non-json-responses.yaml" once using fs.readFileSync, calls
parseYaml to produce an OpenAPISpec (specYaml) and calls generate(specYaml) to
produce result; update each test to use the shared specYaml/result (or call the
helper) instead of re-reading the file. Refer to the repeated symbols
fs.readFileSync, parseYaml, generate, specContent, specYaml, and result when
locating the duplicated logic and replace with the single beforeAll or helper
function.
In @packages/zenko/src/__tests__/oneof-discriminator.test.ts:
- Around line 106-180: The test's assertion uses
result.match(/Foo\.merge/g)?.length which can be undefined; make it null-safe by
coercing to 0 when no matches are found (e.g., use (result.match(/Foo\.merge/g)
|| []).length or (result.match(/Foo\.merge/g)?.length ?? 0)) so the expect call
always receives a number; update the assertion in the test handling
discriminator mapping that references result.match(/Foo\.merge/g) accordingly.
🧹 Nitpick comments (14)
packages/zenko/src/utils/__tests__/topological-sort.test.ts (1)
179-192: Enhance test to verify both discriminator mapping and oneOf dependencies.The test correctly verifies that "Extra" from the discriminator mapping is extracted, but it should also verify that "Payment" from the
oneOfarray is included in dependencies for completeness.♻️ Enhanced test assertions
const deps = extractDependencies(schema) + expect(deps).toHaveLength(2) + expect(deps).toContain("Payment") expect(deps).toContain("Extra")packages/zenko/src/utils/topological-sort.ts (1)
54-60: Consider optimizing to avoid double traversal of the mapping object.The
mappingobject is traversed explicitly at lines 54–60, then traversed again by the generalObject.values(obj).forEach(traverse)call at line 61. While deduplication at line 66 prevents duplicate dependencies, the double traversal is inefficient.The implementation correctly handles OpenAPI 3 discriminator mapping formats (plain schema names, JSON References, and remote URIs) per the specification.
♻️ Optional refactor to eliminate double traversal
+ const keysToSkip = new Set<string>() + if (obj.mapping && typeof obj.mapping === "object") { + keysToSkip.add("mapping") for (const value of Object.values(obj.mapping)) { if (typeof value === "string") { dependencies.push(extractRefName(value)) } } } - Object.values(obj).forEach(traverse) + Object.entries(obj).forEach(([key, value]) => { + if (!keysToSkip.has(key)) traverse(value) + })packages/zenko/src/core/schema-generator.ts (1)
198-282: Consider depth limit for recursive reference detection.The
schemaReferencesNamefunction uses avisitedset to prevent infinite loops when detecting circular references. However, deeply nested schemas without cycles could still cause stack overflow in extreme cases.For test resource processing this is likely fine, but consider adding a depth limit for production robustness if this processes untrusted specs.
packages/zenko/src/__tests__/oneof-discriminator.test.ts (1)
1-4: Fix import order + reuse generated output across tests.Same issues as other tests: built-in imports should come first; avoid repeated fixture IO/parse/generate per test. As per coding guidelines, snapshots should be the primary output verification.
packages/zenko/src/__tests__/anyof-combinations.test.ts (1)
1-4: Deduplicate fixture loading + import order; snapshot can cover most of this.Same pattern: reorder imports (built-in → third-party → local) and compute
resultonce inbeforeAll. As per coding guidelines, prefer the snapshot as the main verification.Also applies to: 5-16
packages/zenko/src/__tests__/complex-composition.test.ts (1)
1-5: Import order + redundantas OpenAPISpec.
- Reorder imports to match guideline (built-in
fsfirst).parseYaml()already returnsOpenAPISpec(perpackages/zenko/src/utils/yaml.ts), soas OpenAPISpecis redundant.Also applies to: 8-13
packages/zenko/src/__tests__/property-metadata.test.ts (1)
1-4: Fix import order and deduplicate YAML loading to improve test reliability and performance.The imports violate the guideline order (should be built-in → third-party → local). More importantly, all 11 tests independently re-read and re-parse the same fixture file, causing unnecessary IO and potential CWD-dependent path failures. Additionally, several tests describe specific behavior (readOnly, writeOnly, deprecated, examples) but only assert generic
toContain("export const X =")checks.Suggested refactor (import order + beforeAll + stable path)
-import { describe, test, expect } from "bun:test" import * as fs from "fs" +import { describe, test, expect, beforeAll } from "bun:test" import { generate, type OpenAPISpec } from "../zenko" describe("Property Metadata", () => { + let result: string + + beforeAll(() => { + const specUrl = new URL("../resources/property-metadata.yaml", import.meta.url) + const specContent = fs.readFileSync(specUrl, "utf8") + const specYaml = Bun.YAML.parse(specContent) as OpenAPISpec + result = generate(specYaml) + }) + test("generates complete TypeScript output", () => { - const specContent = fs.readFileSync( - "src/resources/property-metadata.yaml", - "utf8" - ) - const specYaml = Bun.YAML.parse(specContent) as OpenAPISpec - const result = generate(specYaml) - expect(result).toMatchSnapshot("property-metadata-complete-output") })Additionally, consider strengthening assertions in tests like "handles readOnly properties correctly" and "marks deprecated fields" to verify actual output behavior, not just export presence.
packages/zenko/src/__tests__/additional-properties.test.ts (2)
150-151: Remove semicolons to follow project conventions.The coding guidelines specify no semicolons.
♻️ Proposed fix
- expect(result).toContain( - "export const ArraySchema = z.array(z.string()).min(1);" - ) + expect(result).toContain( + "export const ArraySchema = z.array(z.string()).min(1)" + )
8-11: Consider using path.join or import.meta for robust path resolution.The hardcoded path
"src/resources/additional-properties.yaml"is fragile and may break if the test is run from a different working directory.♻️ Proposed fix using path resolution
+import { join } from "path" + describe("Additional Properties", () => { test("generates complete TypeScript output", () => { const specContent = fs.readFileSync( - "src/resources/additional-properties.yaml", + join(__dirname, "../resources/additional-properties.yaml"), "utf8" )Or if using Bun-specific features:
const specContent = fs.readFileSync( - "src/resources/additional-properties.yaml", + new URL("../resources/additional-properties.yaml", import.meta.url), "utf8" )packages/zenko/src/resources/additional-properties.yaml (2)
1-239: Consider adding security definitions to align with OpenAPI best practices.The static analysis tool flags missing security configuration. While this is acceptable for a test fixture, adding a basic security scheme would make the spec more representative of real-world APIs and improve test coverage.
♻️ Optional addition for improved OpenAPI compliance
components: + securitySchemes: + apiKey: + type: apiKey + in: header + name: X-API-Key + schemas: # Metadata with additionalProperties: true (any additional properties allowed) Metadata:Then optionally add to operations:
/metadata: post: operationId: createMetadata summary: Create metadata with flexible key-value pairs + security: + - apiKey: [] requestBody:Based on static analysis hints.
170-173: Consider adding maxItems constraint to array additionalProperties.The array in
additionalPropertieson line 171-173 lacks amaxItemsconstraint, which could lead to unbounded arrays. Adding a reasonable limit improves API contract clarity.♻️ Proposed addition
additionalProperties: type: array items: type: string + maxItems: 100Based on static analysis hints.
packages/zenko/src/__tests__/non-json-responses.test.ts (3)
12-12: Remove redundant type assertion.The
as OpenAPISpeccast is unnecessary sinceparseYamlalready returnsOpenAPISpecaccording to its type signature inpackages/zenko/src/utils/yaml.ts.- const specYaml = parseYaml(specContent) as OpenAPISpec + const specYaml = parseYaml(specContent)This pattern appears throughout the file and should be removed everywhere.
217-218: Remove semicolons to follow project conventions.Lines 217-218 and 303-309 contain semicolons in string expectations, but the coding guidelines specify no semicolons. If the generated code includes semicolons, this may indicate a generator configuration issue.
♻️ Proposed fixes
- expect(result).toContain('typeof Blob === "undefined"') - expect(result).toContain("z.instanceof(Blob)") + // Verify these match actual generator output without semicolons - expect(result).toContain("export const GetRssFeedResponse = z.string();") + expect(result).toContain("export const GetRssFeedResponse = z.string()") expect(result).toContain( - "export const GetMarkdownDocResponse = z.string();" + "export const GetMarkdownDocResponse = z.string()" )Also applies to: 303-309
8-11: Consider using path.join or import.meta for robust path resolution.Same issue as in the additional-properties test: the hardcoded path
"src/resources/non-json-responses.yaml"is fragile.♻️ Proposed fix
+import { join } from "path" + const specContent = fs.readFileSync( - "src/resources/non-json-responses.yaml", + join(__dirname, "../resources/non-json-responses.yaml"), "utf8" )
📜 Review details
Configuration used: defaults
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (6)
packages/zenko/src/__tests__/__snapshots__/additional-properties.test.ts.snapis excluded by!**/*.snappackages/zenko/src/__tests__/__snapshots__/anyof-combinations.test.ts.snapis excluded by!**/*.snappackages/zenko/src/__tests__/__snapshots__/complex-composition.test.ts.snapis excluded by!**/*.snappackages/zenko/src/__tests__/__snapshots__/form-data.test.ts.snapis excluded by!**/*.snappackages/zenko/src/__tests__/__snapshots__/oneof-discriminator.test.ts.snapis excluded by!**/*.snappackages/zenko/src/__tests__/__snapshots__/property-metadata.test.ts.snapis excluded by!**/*.snap
📒 Files selected for processing (17)
packages/zenko/src/__tests__/additional-properties.test.tspackages/zenko/src/__tests__/anyof-combinations.test.tspackages/zenko/src/__tests__/complex-composition.test.tspackages/zenko/src/__tests__/non-json-responses.test.tspackages/zenko/src/__tests__/oneof-discriminator.test.tspackages/zenko/src/__tests__/property-metadata.test.tspackages/zenko/src/core/__tests__/schema-generator.test.tspackages/zenko/src/core/schema-generator.tspackages/zenko/src/resources/additional-properties.yamlpackages/zenko/src/resources/anyof-combinations.yamlpackages/zenko/src/resources/complex-composition.yamlpackages/zenko/src/resources/non-json-responses.yamlpackages/zenko/src/resources/oneof-discriminator.yamlpackages/zenko/src/resources/property-metadata.yamlpackages/zenko/src/utils/__tests__/topological-sort.test.tspackages/zenko/src/utils/topological-sort.tspackages/zenko/src/zenko.ts
🧰 Additional context used
📓 Path-based instructions (3)
**/*.{ts,tsx,js,jsx}
📄 CodeRabbit inference engine (AGENTS.md)
**/*.{ts,tsx,js,jsx}: Organize imports in this order: built-in → third-party → local; always use double quotes
Use 2 spaces for indentation, no semicolons, trailing commas (ES5), 80 character line width
Use camelCase for variable and function names, PascalCase for class and type names
Prefer Result-style returns or descriptive throws for error handling
Files:
packages/zenko/src/__tests__/oneof-discriminator.test.tspackages/zenko/src/__tests__/complex-composition.test.tspackages/zenko/src/__tests__/additional-properties.test.tspackages/zenko/src/__tests__/property-metadata.test.tspackages/zenko/src/__tests__/non-json-responses.test.tspackages/zenko/src/utils/__tests__/topological-sort.test.tspackages/zenko/src/__tests__/anyof-combinations.test.tspackages/zenko/src/zenko.tspackages/zenko/src/utils/topological-sort.tspackages/zenko/src/core/schema-generator.tspackages/zenko/src/core/__tests__/schema-generator.test.ts
**/*.{ts,tsx}
📄 CodeRabbit inference engine (AGENTS.md)
Export inferred Zod types; keep strict TypeScript with
noUncheckedIndexedAccessandnoUnusedLocalsenabled
Files:
packages/zenko/src/__tests__/oneof-discriminator.test.tspackages/zenko/src/__tests__/complex-composition.test.tspackages/zenko/src/__tests__/additional-properties.test.tspackages/zenko/src/__tests__/property-metadata.test.tspackages/zenko/src/__tests__/non-json-responses.test.tspackages/zenko/src/utils/__tests__/topological-sort.test.tspackages/zenko/src/__tests__/anyof-combinations.test.tspackages/zenko/src/zenko.tspackages/zenko/src/utils/topological-sort.tspackages/zenko/src/core/schema-generator.tspackages/zenko/src/core/__tests__/schema-generator.test.ts
packages/zenko/src/__tests__/**/*.{ts,tsx}
📄 CodeRabbit inference engine (AGENTS.md)
Test specs live in
packages/zenko/src/__tests__; use snapshots for output verification
Files:
packages/zenko/src/__tests__/oneof-discriminator.test.tspackages/zenko/src/__tests__/complex-composition.test.tspackages/zenko/src/__tests__/additional-properties.test.tspackages/zenko/src/__tests__/property-metadata.test.tspackages/zenko/src/__tests__/non-json-responses.test.tspackages/zenko/src/__tests__/anyof-combinations.test.ts
🧠 Learnings (5)
📓 Common learnings
Learnt from: CR
Repo: RawToast/zenko PR: 0
File: AGENTS.md:0-0
Timestamp: 2025-12-16T13:51:25.042Z
Learning: Applies to packages/zenko/src/__tests__/**/*.{ts,tsx} : Test specs live in `packages/zenko/src/__tests__`; use snapshots for output verification
📚 Learning: 2025-12-16T13:51:25.042Z
Learnt from: CR
Repo: RawToast/zenko PR: 0
File: AGENTS.md:0-0
Timestamp: 2025-12-16T13:51:25.042Z
Learning: Applies to packages/zenko/src/__tests__/**/*.{ts,tsx} : Test specs live in `packages/zenko/src/__tests__`; use snapshots for output verification
Applied to files:
packages/zenko/src/__tests__/oneof-discriminator.test.tspackages/zenko/src/__tests__/complex-composition.test.tspackages/zenko/src/__tests__/additional-properties.test.tspackages/zenko/src/__tests__/property-metadata.test.tspackages/zenko/src/__tests__/non-json-responses.test.tspackages/zenko/src/utils/__tests__/topological-sort.test.tspackages/zenko/src/__tests__/anyof-combinations.test.tspackages/zenko/src/zenko.tspackages/zenko/src/core/__tests__/schema-generator.test.ts
📚 Learning: 2025-10-16T00:11:55.898Z
Learnt from: RawToast
Repo: RawToast/zenko PR: 15
File: packages/zenko/src/zenko.ts:917-921
Timestamp: 2025-10-16T00:11:55.898Z
Learning: In packages/zenko/src/zenko.ts, the `response` field in operation objects can contain TypeScript type expressions like `z.ZodArray<typeof SchemaName>` for inline array responses. These expressions are intended for type definitions and type checking, not for runtime validation. Users should not attempt to use these type expressions as runtime Zod schemas.
Applied to files:
packages/zenko/src/__tests__/additional-properties.test.tspackages/zenko/src/__tests__/property-metadata.test.tspackages/zenko/src/__tests__/non-json-responses.test.tspackages/zenko/src/zenko.tspackages/zenko/src/core/schema-generator.tspackages/zenko/src/core/__tests__/schema-generator.test.ts
📚 Learning: 2025-12-16T13:51:25.042Z
Learnt from: CR
Repo: RawToast/zenko PR: 0
File: AGENTS.md:0-0
Timestamp: 2025-12-16T13:51:25.042Z
Learning: Applies to **/*.{ts,tsx} : Export inferred Zod types; keep strict TypeScript with `noUncheckedIndexedAccess` and `noUnusedLocals` enabled
Applied to files:
packages/zenko/src/__tests__/non-json-responses.test.ts
📚 Learning: 2025-10-31T22:24:57.504Z
Learnt from: RawToast
Repo: RawToast/zenko PR: 34
File: packages/zenko/src/__tests__/config-options.test.ts:473-556
Timestamp: 2025-10-31T22:24:57.504Z
Learning: In the zenko package, the `optionalType` configuration option has three distinct behaviors aligned with Zod semantics: `optional` generates `.optional()` (field can be undefined/omitted), `nullable` generates `.nullable()` (field must be present but can be null), and `nullish` generates `.nullish()` (field can be undefined OR null). The `nullable` option intentionally does NOT add `.optional()`, as that would change the required/optional nature of the field.
Applied to files:
packages/zenko/src/core/schema-generator.tspackages/zenko/src/core/__tests__/schema-generator.test.ts
🧬 Code graph analysis (10)
packages/zenko/src/__tests__/oneof-discriminator.test.ts (1)
packages/zenko/src/zenko.ts (2)
OpenAPISpec(25-34)generate(434-439)
packages/zenko/src/__tests__/complex-composition.test.ts (2)
packages/zenko/src/utils/yaml.ts (1)
parseYaml(9-11)packages/zenko/src/zenko.ts (2)
OpenAPISpec(25-34)generate(434-439)
packages/zenko/src/__tests__/additional-properties.test.ts (3)
packages/examples/generate.js (2)
specContent(13-13)spec(20-20)packages/zenko/src/utils/yaml.ts (1)
parseYaml(9-11)packages/zenko/src/zenko.ts (2)
generate(434-439)OpenAPISpec(25-34)
packages/zenko/src/__tests__/property-metadata.test.ts (2)
packages/examples/generate.js (1)
specContent(13-13)packages/zenko/src/zenko.ts (2)
OpenAPISpec(25-34)generate(434-439)
packages/zenko/src/__tests__/non-json-responses.test.ts (3)
packages/examples/generate.js (1)
specContent(13-13)packages/zenko/src/utils/yaml.ts (1)
parseYaml(9-11)packages/zenko/src/zenko.ts (2)
OpenAPISpec(25-34)generate(434-439)
packages/zenko/src/utils/__tests__/topological-sort.test.ts (1)
packages/zenko/src/utils/topological-sort.ts (1)
extractDependencies(39-67)
packages/zenko/src/__tests__/anyof-combinations.test.ts (1)
packages/zenko/src/zenko.ts (2)
OpenAPISpec(25-34)generate(434-439)
packages/zenko/src/zenko.ts (1)
packages/examples/generate.js (1)
spec(20-20)
packages/zenko/src/core/schema-generator.ts (1)
packages/zenko/src/utils/topological-sort.ts (1)
extractRefName(69-71)
packages/zenko/src/core/__tests__/schema-generator.test.ts (1)
packages/zenko/src/core/schema-generator.ts (1)
getZodTypeFromSchema(518-685)
🪛 Checkov (3.2.334)
packages/zenko/src/resources/property-metadata.yaml
[high] 1-307: Ensure that the global security field has rules defined
(CKV_OPENAPI_4)
[high] 1-307: Ensure that security operations is not empty.
(CKV_OPENAPI_5)
[medium] 297-302: Ensure that arrays have a maximum number of items
(CKV_OPENAPI_21)
packages/zenko/src/resources/anyof-combinations.yaml
[high] 1-214: Ensure that the global security field has rules defined
(CKV_OPENAPI_4)
[high] 1-214: Ensure that security operations is not empty.
(CKV_OPENAPI_5)
[medium] 48-53: Ensure that arrays have a maximum number of items
(CKV_OPENAPI_21)
packages/zenko/src/resources/additional-properties.yaml
[high] 1-241: Ensure that the global security field has rules defined
(CKV_OPENAPI_4)
[high] 1-241: Ensure that security operations is not empty.
(CKV_OPENAPI_5)
[medium] 171-177: Ensure that arrays have a maximum number of items
(CKV_OPENAPI_21)
packages/zenko/src/resources/non-json-responses.yaml
[high] 1-324: Ensure that the global security field has rules defined
(CKV_OPENAPI_4)
[high] 1-324: Ensure that security operations is not empty.
(CKV_OPENAPI_5)
[medium] 47-60: Ensure that arrays have a maximum number of items
(CKV_OPENAPI_21)
packages/zenko/src/resources/oneof-discriminator.yaml
[high] 1-213: Ensure that the global security field has rules defined
(CKV_OPENAPI_4)
[high] 1-213: Ensure that security operations is not empty.
(CKV_OPENAPI_5)
packages/zenko/src/resources/complex-composition.yaml
[high] 1-418: Ensure that the global security field has rules defined
(CKV_OPENAPI_4)
[high] 1-418: Ensure that security operations is not empty.
(CKV_OPENAPI_5)
[medium] 203-207: Ensure that arrays have a maximum number of items
(CKV_OPENAPI_21)
🔇 Additional comments (13)
packages/zenko/src/resources/property-metadata.yaml (1)
1-305: LGTM - Well-structured test specification for property metadata.This OpenAPI spec comprehensively covers the intended metadata features (readOnly, writeOnly, const, default, deprecated, examples) across multiple schema types. The static analysis warnings about missing security definitions (CKV_OPENAPI_4/5) and array maxItems (CKV_OPENAPI_21) can be safely ignored since this is a test resource fixture, not a production API specification.
packages/zenko/src/resources/non-json-responses.yaml (1)
1-322: LGTM - Comprehensive test specification for non-JSON response types.This spec provides excellent coverage for testing code generation of various content types including CSV, XML, binary streams, PDF, images, plain text, SSE, markdown, and syndication feeds. The static analysis warnings about security definitions and array bounds are acceptable for test resource files.
packages/zenko/src/resources/oneof-discriminator.yaml (1)
1-211: LGTM - Good coverage of discriminator patterns.This spec effectively tests both discriminator approaches:
- Payment with explicit
discriminator.mappinglinking string values to schema refs- Vehicle without explicit mapping, relying on
constvalues in each variantThe patterns and constraints are well-defined for their test purposes. Static analysis security warnings can be ignored for test fixtures.
packages/zenko/src/core/schema-generator.ts (4)
481-512: LGTM - Discriminated union builder with proper fallback.The logic correctly:
- Handles empty/single schema edge cases
- Falls back to
z.unionwhen unmapped schemas exist (Line 508-509)- Uses
z.discriminatedUniononly when all schemas have discriminator values
555-579: LGTM - Not-schema handling generates correct refinements.The implementation correctly generates:
- Special case for "not empty string" using a simpler length check (Line 568-569)
- General case using
safeParserefinement for complex not-schemas (Line 578)Since this is code generation, the generated TypeScript will have the schema in scope when the refinement runs.
772-798: LGTM - additionalProperties handling covers all cases.The implementation correctly maps OpenAPI semantics to Zod:
undefined→ base object (default Zod behavior strips unknown keys)false→.strict()(reject unknown keys)true→.passthrough()(allow any additional properties)- Schema object →
.catchall(type)(typed additional properties)
687-718: LGTM - Discriminator property requirement detection.This function correctly scans the schema registry to find discriminator properties that must be required when a schema participates in a discriminated union. This ensures the generated Zod schema properly validates discriminator fields.
packages/zenko/src/resources/complex-composition.yaml (1)
1-416: LGTM - Comprehensive test specification for complex compositions.This spec provides excellent coverage for testing:
- Multi-level allOf compositions (BaseEntity composing Identifiable, Timestamped, Versioned)
- Discriminated unions with and without explicit mappings (Entity, ContentBlock)
- Recursive types (HierarchicalData referencing itself)
- Nullable unions using
anyOfwithtype: "null"- Not constraints (NotEmptyString)
- Nested oneOf within allOf (ConfigurableItem)
Static analysis warnings are acceptable for test fixtures.
packages/zenko/src/zenko.ts (1)
163-172: LGTM - Schema registry integration.The addition of
spec.components.schemasas the sixth argument enables the enhanced schema generation capabilities:
- Mutual recursion detection for
z.lazy()generation- Discriminator-aware required property handling
- Reference resolution for complex compositions
This is a minimal, well-scoped change that maintains backward compatibility since the parameter is optional.
packages/zenko/src/core/__tests__/schema-generator.test.ts (3)
378-398: LGTM - Mutual recursion test validates z.lazy generation.This test correctly validates that mutually recursive schemas (A references B, B references A) generate
z.lazy(() => B)when processing schema A. The test structure with explicit schemaRegistry and currentSchemaName parameters exercises the new recursion detection logic.
407-416: LGTM - Not-schema test validates constraint preservation.This test ensures that when a
notconstraint is applied, the base schema's constraints (likeformat: "email") are preserved in the generated output. This validates the correct behavior of the not-schema handling ingetZodTypeFromSchema.
423-445: LGTM - Updated allOf tests reflect merge strategy change.The expectation changes from
.and()to.merge()align with the newisObjectSchemacheck that determines the join method. For object schemas,.merge()is semantically correct as it properly combines object types, while.and()creates an intersection which can be problematic for Zod object manipulation.The new sibling properties test (Lines 434-445) validates that properties defined alongside
allOfare properly merged into the result.packages/zenko/src/__tests__/non-json-responses.test.ts (1)
6-6: Entire test suite is skipped—verify this is intentional.The
describe.skipmeans none of these 17 tests are executing. If this is temporary scaffolding, consider adding a TODO comment explaining when they'll be enabled. If unintentional, remove the.skip.
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #53 +/- ##
==========================================
+ Coverage 96.48% 97.29% +0.80%
==========================================
Files 14 14
Lines 1622 2141 +519
==========================================
+ Hits 1565 2083 +518
- Misses 57 58 +1 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
There was a problem hiding this comment.
Actionable comments posted: 9
🤖 Fix all issues with AI agents
In @packages/zenko/src/__tests__/anyof-combinations.test.ts:
- Around line 89-110: The order test uses result.indexOf(...) which returns -1
for missing strings, allowing the less-than assertions to false-pass; update the
test "maintains schema dependency order with anyOf" to first assert that each
index variable (textFilterIndex, dateRangeFilterIndex, numericRangeFilterIndex,
searchFilterIndex) is not -1 (e.g., expect(...).toBeGreaterThan(-1) or
toBeGreaterThanOrEqual(0)) before performing the existing
expect(...).toBeLessThan(searchFilterIndex) comparisons so missing schemas fail
the test instead of causing misleading passes.
- Around line 74-87: The test currently only asserts the export exists for
FlexibleData; update it to verify the actual union shape by asserting that the
generated output (variable result) contains the expected union fragments for
FlexibleData (e.g., "export const FlexibleData =", "z.union([", and the
primitive/complex schema pieces such as "z.string()", "z.number()",
"z.boolean()", "z.array(", "z.object(") or replace/add a snapshot assertion for
the entire FlexibleData export block to lock its generated shape; locate the
FlexibleData export in the generate output and add assertions (or a snapshot)
rather than leaving the commented expectation.
- Around line 1-3: Reorder the imports so built-in modules come first: move the
fs import above the third-party import; specifically change the import order to
import * as fs from "fs" first, then import { describe, test, expect } from
"bun:test", and finally import { generate, type OpenAPISpec } from "../zenko" to
conform to built-in → third-party → local guidelines.
- Around line 35-51: Narrow the assertions to only the generated Contact export
instead of scanning the entire result: extract or match the "export const
Contact =" block from result (e.g., via a scoped regex that captures from
"export const Contact =" through the block end) and assert that this extracted
Contact text contains "email" and "phone" and the expected anyOf/required
validation, or replace those asserts with a snapshot of just the Contact
section; update the test to use this scoped match/snapshot so unrelated
occurrences of "email"/"phone" in result cannot make the test pass.
- Around line 127-141: The test that checks the generated signature for
searchItems is brittle because it matches a long exact string; update the test
(in anyof-combinations.test.ts) to assert smaller, stable substrings instead of
the full signature: verify result includes "searchItems:" and that the function
signature contains "{ query" and "filter?:", and keep the existing assertion
that result contains 'params.set("filter", String(filter))' (or alternatively
use a regex like /searchItems:\s*\(\{[^}]*query[^}]*filter\?:/ to combine
checks).
- Around line 6-15: Tests in anyof-combinations.test.ts read the fixture via a
CWD-dependent string ("src/resources/anyof-combinations.yaml") and duplicate the
same load/parse logic across 9 tests; extract a shared helper that resolves the
fixture path from import.meta.url and centralizes reading and parsing, then
replace each test's fs.readFileSync(...), Bun.YAML.parse(...) and OpenAPISpec
cast with a call to that helper before invoking generate; reference the existing
symbols used in the file (fs.readFileSync, Bun.YAML.parse, OpenAPISpec,
generate, and the test blocks) when implementing the helper and update all nine
tests to call it so paths no longer depend on the current working directory.
In @packages/zenko/src/__tests__/oneof-discriminator.test.ts:
- Around line 227-246: The test can false-pass if indexOf returns -1; update the
test around the symbols CreditCardPayment, BankTransferPayment, CryptoPayment
and Payment to first assert each variant index is found (not -1) before
asserting they come before the Payment index, e.g., check creditCardIndex !==
-1, bankTransferIndex !== -1, cryptoIndex !== -1 (or use
expect(...).not.toBe(-1)) and then assert creditCardIndex < paymentIndex,
bankTransferIndex < paymentIndex, and cryptoIndex < paymentIndex.
- Around line 1-3: The import order is wrong: place built-in modules before
third-party ones — move the fs import above the bun:test import so that "fs" is
imported before "bun:test"; keep the local import of generate/type OpenAPISpec
from "../zenko" after third-party imports to maintain built-in → third-party →
local ordering.
- Around line 106-180: The test "handles discriminator mapping correctly" is
fragile and uses an invalid OpenAPI mapping; update it to use a snapshot for the
full generated output from generate(specYaml) instead of counting occurrences of
"Foo.merge", and either fix the specYaml so all discriminator mapping targets
(e.g., "Extra") are included in the Payment.oneOf array or add a clear comment
and an explicit assertion that validates error/handling behavior for a malformed
spec; specifically, replace the brittle expect(...Foo.merge...) checks with
expect(result).toMatchSnapshot() (or equivalent snapshot helper), and ensure
specYaml.components.schemas.Payment.oneOf includes the Extra schema if you
intend a valid spec, or document the invalidity and assert the generator returns
an error/handles it accordingly.
🧹 Nitpick comments (3)
packages/zenko/src/__tests__/complex-composition.test.ts (1)
8-12: Consider extracting the file read operation to reduce duplication.The same file is read and parsed 15 times across different tests. This violates the DRY principle and impacts test performance.
♻️ Refactor to shared setup
You can extract the file reading to a describe-level variable or use a helper:
describe("Complex Composition", () => { + const getComplexCompositionSpec = (() => { + let cached: { spec: OpenAPISpec; result: string } | null = null + return () => { + if (!cached) { + const specContent = fs.readFileSync( + "src/resources/complex-composition.yaml", + "utf8" + ) + const spec = parseYaml(specContent) as OpenAPISpec + const result = generate(spec) + cached = { spec, result } + } + return cached + } + })() + test("generates complete TypeScript output", () => { - const specContent = fs.readFileSync( - "src/resources/complex-composition.yaml", - "utf8" - ) - const specYaml = parseYaml(specContent) as OpenAPISpec - const result = generate(specYaml) + const { result } = getComplexCompositionSpec() expect(result).toMatchSnapshot("complex-composition-complete-output") }) test("handles allOf with multiple schema references", () => { - const specContent = fs.readFileSync( - "src/resources/complex-composition.yaml", - "utf8" - ) - const specYaml = parseYaml(specContent) as OpenAPISpec - const result = generate(specYaml) + const { result } = getComplexCompositionSpec() // BaseEntity uses allOf with three refs + inline object expect(result).toContain("export const BaseEntity =")Apply the same pattern to all tests that use the complex-composition.yaml file.
Also applies to: 19-23, 37-41, 55-59, 77-81, 96-100, 115-119, 132-136, 148-152, 166-170, 181-185, 198-202, 216-220, 279-283, 302-306, 344-348, 357-361
packages/zenko/src/__tests__/oneof-discriminator.test.ts (2)
14-15: Consider snapshots for the inline-spec cases (mapping/fallback), not just fixture output.
Right now only the fixture test snapshots output; the inline discriminator-mapping/fallback tests are more likely to regress and would benefit from snapshotting their generated output too. Based on learnings, snapshots are the preferred output verification in this test area.Also applies to: 17-105, 106-225
6-24: Extract repetitive fixture loading into a helper and fix import order.The fixture path
"src/resources/oneof-discriminator.yaml"depends on test working directory, making tests brittle. Additionally, the same YAML parsing pattern repeats across 7 tests (lines 6–15, 17–31, 33–52, 54–71, 73–89, 91–104, 227–246).Extract this into a helper function. Note: Bun's
fs.readFileSyncaccepts WHATWG URL objects directly, sofileURLToPathis unnecessary. Also, imports must follow the guideline order (built-in → third-party → local): move"fs"before"bun:test".Proposed refactor
import * as fs from "fs" import { describe, test, expect } from "bun:test" import { generate, type OpenAPISpec } from "../zenko" +const FIXTURE_PATH = new URL("../resources/oneof-discriminator.yaml", import.meta.url) + +function generateFromFixture() { + const specContent = fs.readFileSync(FIXTURE_PATH, "utf8") + const specYaml = Bun.YAML.parse(specContent) as OpenAPISpec + return generate(specYaml) +} + describe("oneOf with Discriminator", () => { test("generates complete TypeScript output", () => { - const specContent = fs.readFileSync( - "src/resources/oneof-discriminator.yaml", - "utf8" - ) - const specYaml = Bun.YAML.parse(specContent) as OpenAPISpec - const result = generate(specYaml) + const result = generateFromFixture() expect(result).toMatchSnapshot("oneof-discriminator-complete-output") }) test("generates discriminated union for Payment with z.discriminatedUnion", () => { - const specContent = fs.readFileSync( - "src/resources/oneof-discriminator.yaml", - "utf8" - ) - const specYaml = Bun.YAML.parse(specContent) as OpenAPISpec - const result = generate(specYaml) + const result = generateFromFixture()
📜 Review details
Configuration used: defaults
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (1)
bun.lockis excluded by!**/*.lock
📒 Files selected for processing (5)
packages/zenko/src/__tests__/additional-properties.test.tspackages/zenko/src/__tests__/anyof-combinations.test.tspackages/zenko/src/__tests__/complex-composition.test.tspackages/zenko/src/__tests__/non-json-responses.test.tspackages/zenko/src/__tests__/oneof-discriminator.test.ts
🚧 Files skipped from review as they are similar to previous changes (2)
- packages/zenko/src/tests/additional-properties.test.ts
- packages/zenko/src/tests/non-json-responses.test.ts
🧰 Additional context used
📓 Path-based instructions (3)
**/*.{ts,tsx,js,jsx}
📄 CodeRabbit inference engine (AGENTS.md)
**/*.{ts,tsx,js,jsx}: Organize imports in this order: built-in → third-party → local; always use double quotes
Use 2 spaces for indentation, no semicolons, trailing commas (ES5), 80 character line width
Use camelCase for variable and function names, PascalCase for class and type names
Prefer Result-style returns or descriptive throws for error handling
Files:
packages/zenko/src/__tests__/anyof-combinations.test.tspackages/zenko/src/__tests__/oneof-discriminator.test.tspackages/zenko/src/__tests__/complex-composition.test.ts
**/*.{ts,tsx}
📄 CodeRabbit inference engine (AGENTS.md)
Export inferred Zod types; keep strict TypeScript with
noUncheckedIndexedAccessandnoUnusedLocalsenabled
Files:
packages/zenko/src/__tests__/anyof-combinations.test.tspackages/zenko/src/__tests__/oneof-discriminator.test.tspackages/zenko/src/__tests__/complex-composition.test.ts
packages/zenko/src/__tests__/**/*.{ts,tsx}
📄 CodeRabbit inference engine (AGENTS.md)
Test specs live in
packages/zenko/src/__tests__; use snapshots for output verification
Files:
packages/zenko/src/__tests__/anyof-combinations.test.tspackages/zenko/src/__tests__/oneof-discriminator.test.tspackages/zenko/src/__tests__/complex-composition.test.ts
🧠 Learnings (2)
📚 Learning: 2025-12-16T13:51:25.042Z
Learnt from: CR
Repo: RawToast/zenko PR: 0
File: AGENTS.md:0-0
Timestamp: 2025-12-16T13:51:25.042Z
Learning: Applies to packages/zenko/src/__tests__/**/*.{ts,tsx} : Test specs live in `packages/zenko/src/__tests__`; use snapshots for output verification
Applied to files:
packages/zenko/src/__tests__/anyof-combinations.test.tspackages/zenko/src/__tests__/oneof-discriminator.test.tspackages/zenko/src/__tests__/complex-composition.test.ts
📚 Learning: 2025-10-16T00:11:55.898Z
Learnt from: RawToast
Repo: RawToast/zenko PR: 15
File: packages/zenko/src/zenko.ts:917-921
Timestamp: 2025-10-16T00:11:55.898Z
Learning: In packages/zenko/src/zenko.ts, the `response` field in operation objects can contain TypeScript type expressions like `z.ZodArray<typeof SchemaName>` for inline array responses. These expressions are intended for type definitions and type checking, not for runtime validation. Users should not attempt to use these type expressions as runtime Zod schemas.
Applied to files:
packages/zenko/src/__tests__/complex-composition.test.ts
🧬 Code graph analysis (3)
packages/zenko/src/__tests__/anyof-combinations.test.ts (2)
packages/examples/generate.js (1)
specContent(13-13)packages/zenko/src/zenko.ts (2)
OpenAPISpec(25-34)generate(434-439)
packages/zenko/src/__tests__/oneof-discriminator.test.ts (2)
packages/examples/generate.js (1)
specContent(13-13)packages/zenko/src/zenko.ts (2)
OpenAPISpec(25-34)generate(434-439)
packages/zenko/src/__tests__/complex-composition.test.ts (2)
packages/zenko/src/utils/yaml.ts (1)
parseYaml(9-11)packages/zenko/src/zenko.ts (2)
OpenAPISpec(25-34)generate(434-439)
🔇 Additional comments (5)
packages/zenko/src/__tests__/complex-composition.test.ts (3)
1-4: LGTM! Imports follow coding guidelines.The import order (built-in → local) and double-quote usage align with the project's coding standards.
6-368: Comprehensive test coverage for complex OpenAPI compositions.The test suite thoroughly validates:
- allOf/oneOf/anyOf composition handling
- Discriminated unions with const discriminators
- Recursive schemas with z.lazy
- Null handling in unions
- Schema dependency ordering
- Default value propagation
The assertions are specific and verify both presence and absence of expected patterns, which helps catch regressions.
234-276: Well-scoped edge case tests with inline specs.Using inline YAML specifications for these focused edge cases (non-primitive const, single-value enums) is appropriate and keeps the main complex-composition.yaml focused on comprehensive scenarios.
packages/zenko/src/__tests__/oneof-discriminator.test.ts (1)
5-105: Test coverage is solid and targets the right failure modes for discriminator codegen.
Fixture snapshot + focused assertions arounddiscriminatedUnion, literal discriminator values, and operation typing gives good regression protection.packages/zenko/src/__tests__/anyof-combinations.test.ts (1)
143-160: Discriminator literal checks look good.
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (1)
packages/zenko/src/__tests__/anyof-combinations.test.ts (1)
9-34: Helper functions are well-designed; consider minor style adjustments.The helper functions provide good abstractions for test setup:
resolveFixturecorrectly usesimport.meta.urlfor CWD-independent pathsloadSpecproperly leverages Bun's native YAML parsingextractExportBlockhandles missing schemas gracefully by returning nullRegarding the static analysis warning on the regex construction (lines 28-30): the ReDoS risk is negligible here because
schemaNameis controlled test input (not user-supplied), the pattern uses a lazy quantifier with a clear terminator, and this is non-production test code.However, the file uses semicolons throughout (lines 11, 19, 33), which deviates from the coding guideline preference for no semicolons.
🎨 Optional: Remove semicolons per coding guidelines
function resolveFixture(filename: string): string { const testDir = path.dirname(new URL(import.meta.url).pathname) - return path.join(testDir, "..", "resources", filename); + return path.join(testDir, "..", "resources", filename) } function loadSpec(filename: string): OpenAPISpec { const content = fs.readFileSync(resolveFixture(filename), "utf8") - return Bun.YAML.parse(content) as OpenAPISpec; + return Bun.YAML.parse(content) as OpenAPISpec } function extractExportBlock(result: string, schemaName: string): string | null { const pattern = new RegExp( `(export const ${schemaName} = [\\s\\S]*?;)\\n`, "m" ) const match = result.match(pattern) - return match?.[1]?.trim() ?? null; + return match?.[1]?.trim() ?? null }As per coding guidelines, the project prefers no semicolons.
📜 Review details
Configuration used: defaults
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (4)
codecov.ymlpackages/zenko/src/__tests__/anyof-combinations.test.tspackages/zenko/src/__tests__/oneof-discriminator.test.tspackages/zenko/src/core/__tests__/schema-generator.test.ts
✅ Files skipped from review due to trivial changes (1)
- codecov.yml
🚧 Files skipped from review as they are similar to previous changes (1)
- packages/zenko/src/core/tests/schema-generator.test.ts
🧰 Additional context used
📓 Path-based instructions (3)
**/*.{ts,tsx,js,jsx}
📄 CodeRabbit inference engine (AGENTS.md)
**/*.{ts,tsx,js,jsx}: Organize imports in this order: built-in → third-party → local; always use double quotes
Use 2 spaces for indentation, no semicolons, trailing commas (ES5), 80 character line width
Use camelCase for variable and function names, PascalCase for class and type names
Prefer Result-style returns or descriptive throws for error handling
Files:
packages/zenko/src/__tests__/oneof-discriminator.test.tspackages/zenko/src/__tests__/anyof-combinations.test.ts
**/*.{ts,tsx}
📄 CodeRabbit inference engine (AGENTS.md)
Export inferred Zod types; keep strict TypeScript with
noUncheckedIndexedAccessandnoUnusedLocalsenabled
Files:
packages/zenko/src/__tests__/oneof-discriminator.test.tspackages/zenko/src/__tests__/anyof-combinations.test.ts
packages/zenko/src/__tests__/**/*.{ts,tsx}
📄 CodeRabbit inference engine (AGENTS.md)
Test specs live in
packages/zenko/src/__tests__; use snapshots for output verification
Files:
packages/zenko/src/__tests__/oneof-discriminator.test.tspackages/zenko/src/__tests__/anyof-combinations.test.ts
🧠 Learnings (3)
📚 Learning: 2025-12-16T13:51:25.042Z
Learnt from: CR
Repo: RawToast/zenko PR: 0
File: AGENTS.md:0-0
Timestamp: 2025-12-16T13:51:25.042Z
Learning: Applies to packages/zenko/src/__tests__/**/*.{ts,tsx} : Test specs live in `packages/zenko/src/__tests__`; use snapshots for output verification
Applied to files:
packages/zenko/src/__tests__/oneof-discriminator.test.tspackages/zenko/src/__tests__/anyof-combinations.test.ts
📚 Learning: 2025-12-16T13:51:25.042Z
Learnt from: CR
Repo: RawToast/zenko PR: 0
File: AGENTS.md:0-0
Timestamp: 2025-12-16T13:51:25.042Z
Learning: Applies to **/*.{ts,tsx,js,jsx} : Organize imports in this order: built-in → third-party → local; always use double quotes
Applied to files:
packages/zenko/src/__tests__/oneof-discriminator.test.tspackages/zenko/src/__tests__/anyof-combinations.test.ts
📚 Learning: 2025-12-16T13:51:25.042Z
Learnt from: CR
Repo: RawToast/zenko PR: 0
File: AGENTS.md:0-0
Timestamp: 2025-12-16T13:51:25.042Z
Learning: Applies to **/*.{ts,tsx} : Export inferred Zod types; keep strict TypeScript with `noUncheckedIndexedAccess` and `noUnusedLocals` enabled
Applied to files:
packages/zenko/src/__tests__/anyof-combinations.test.ts
🧬 Code graph analysis (2)
packages/zenko/src/__tests__/oneof-discriminator.test.ts (1)
packages/zenko/src/zenko.ts (2)
OpenAPISpec(25-34)generate(434-439)
packages/zenko/src/__tests__/anyof-combinations.test.ts (1)
packages/zenko/src/zenko.ts (2)
OpenAPISpec(25-34)generate(434-439)
🪛 ast-grep (0.40.4)
packages/zenko/src/__tests__/anyof-combinations.test.ts
[warning] 27-30: Regular expression constructed from variable input detected. This can lead to Regular Expression Denial of Service (ReDoS) attacks if the variable contains malicious patterns. Use libraries like 'recheck' to validate regex safety or use static patterns.
Context: new RegExp(
(export const ${schemaName} = [\\s\\S]*?;)\\n,
"m"
)
Note: [CWE-1333] Inefficient Regular Expression Complexity [REFERENCES]
- https://owasp.org/www-community/attacks/Regular_expression_Denial_of_Service_-_ReDoS
- https://cwe.mitre.org/data/definitions/1333.html
(regexp-from-variable)
🔇 Additional comments (4)
packages/zenko/src/__tests__/anyof-combinations.test.ts (3)
1-4: LGTM! Import organization follows guidelines.The imports are correctly ordered (built-in → third-party → local) and consistently use double quotes.
36-43: LGTM! Efficient test setup.Using
beforeAllto load the spec and generate output once for all tests is an efficient pattern that avoids redundant work.
45-151: LGTM! Comprehensive and well-structured test suite.The test cases provide excellent coverage of anyOf scenarios:
- Snapshot validation for full output verification (aligns with coding guidelines)
- Union generation and variant schema exports
- Inline constraints and discriminated unions
- Primitive type handling and mixed unions
- Critical schema dependency ordering validation
- Operation and parameter typing
Each test is focused, atomic, and uses appropriate assertions. The dependency order test (lines 99-120) is particularly valuable for ensuring correct code generation sequencing.
packages/zenko/src/__tests__/oneof-discriminator.test.ts (1)
1-240: Excellent test coverage and implementation!This test file demonstrates high quality and thoroughness:
- Follows all coding guidelines (import order, formatting, naming conventions)
- Comprehensive coverage of oneOf discriminator functionality including edge cases
- Appropriate use of snapshots for output verification per project guidelines
- Well-documented inline specs for testing edge cases (discriminator mapping irregularities, missing discriminator values)
- Proper test isolation with
beforeAllfor performance- Clear, descriptive test names and helpful comments explaining complex scenarios
The inline OpenAPI specs (lines 93-159, 175-213) are substantial but appropriately kept inline rather than extracted to fixtures, as they document specific edge cases being tested.
This commit adds 7 new test modules and schemas covering critical gaps in OpenAPI specification compliance: 1. oneOf with discriminator - Polymorphic types with discriminated unions 2. anyOf combinations - Flexible schema matching and unions 3. Property metadata - readOnly, writeOnly, const, default, deprecated 4. Additional properties - Flexible object schemas with additionalProperties 5. Form data - multipart/form-data and application/x-www-form-urlencoded 6. Complex composition - Nested allOf + oneOf + anyOf + not 7. Non-JSON responses - CSV, XML, binary, text, streaming responses All tests are marked with .skip() as they test features not yet implemented. Each test includes: - Comprehensive snapshot testing - Specific feature validation - Schema dependency order checks - Operation object validation Tests follow existing patterns: - Located in packages/zenko/src/__tests__/ - Schemas in packages/zenko/src/resources/ - Use bun:test framework - Include both positive and edge case assertions Total: 94 skipped tests (8+9+13+15+18+15+16) covering major OpenAPI 3.0/3.1 gaps
RawToast
force-pushed
the
claude/verify-openapi-compliance-01FZcvdMDyBV25q9FAWhPoHe
branch
from
7c89706 to
cd9807e
Compare
RawToast
deleted the
claude/verify-openapi-compliance-01FZcvdMDyBV25q9FAWhPoHe
branch
2 participants
Summary by CodeRabbit
New Features
Tests
✏️ Tip: You can customize this high-level summary in your review settings.