-
Notifications
You must be signed in to change notification settings - Fork 1
fix: type in SchemaObject can be an array #3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
WalkthroughA new Changes
Sequence Diagram(s)sequenceDiagram
participant User
participant SchemaSystem
User->>SchemaSystem: Define schema with type: ["string", "null"]
SchemaSystem->>SchemaSystem: Match schema to UnionSchema type
SchemaSystem-->>User: Accepts union type schema
Estimated code review effort🎯 2 (Simple) | ⏱️ ~7 minutes Assessment against linked issues
Poem
Note ⚡️ Unit Test Generation is now available in beta!Learn more here, or try it out under "Finishing Touches" below. 📜 Recent review detailsConfiguration used: CodeRabbit UI 📒 Files selected for processing (1)
🚧 Files skipped from review as they are similar to previous changes (1)
✨ Finishing Touches
🧪 Generate unit tests
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. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
fed86eb to
5d8d393
Compare
5d8d393 to
8b2e279
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 0
🧹 Nitpick comments (1)
src/schema.ts (1)
89-93: Consider the type safety implications of the union property approach.The current
UnionSchemaimplementation creates a union of all type-specific properties, meaning a schema withtype: ["string", "number"]would expose properties from both string AND number types simultaneously. This might lead to confusing IntelliSense suggestions and doesn't accurately represent the JSON Schema semantics where union types validate against ANY of the specified types.Consider whether this approach aligns with the intended usage patterns or if a more restrictive type definition would be more appropriate.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
src/schema.ts(1 hunks)
🔇 Additional comments (2)
src/schema.ts (2)
27-83: Excellent refactoring to consolidate type-specific properties!The new
TypeSpecificsmapped type effectively consolidates all type-specific schema properties into a clean, maintainable structure. The approach of separating type-specific properties from thetypediscriminator enables flexible composition in the updatedSchemaObjectdefinition.
98-100: SchemaObject update is well-designed — requires manual validationThe new mapped type over
TypeSpecifics, unioned withUnionSchemaand the legacy reference fallback, cleanly supports both single and array types per OpenAPI 3.1. Automated searches in TS/TSX, JSON, and YAML fixtures did not locate any literaltype: "<kind>"usages, so please manually verify that existing single‐type schemas continue to work end-to-end:
- Ensure unit and integration tests covering
{ type: "string" },{ type: "number" }, etc., still pass.- Confirm any JSON/YAML example fixtures or runtime‐loaded schemas with
type: "<kind>"behave as expected.
8b2e279 to
c5d9c01
Compare
Fixes #2.
Summary by CodeRabbit