You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
* test: add failing test for anonymous recursive type in wrapper
Reveals bug where anonymous recursive types inside wrappers
(e.g., Default<{ self: Root }, {}>) create dangling $ref because
the synthetic name is created by cycle detection but never stored
in definitions due to isWrapperContext check.
The test shows that when an anonymous object type containing a
recursive reference is wrapped in Default/Cell/Stream, the cycle
detection correctly creates AnonymousType_1 and emits a $ref to it,
but the definition is never stored in $defs because line 224 in
schema-generator.ts prevents synthetic names from being used when
isWrapperContext is true.
Reported by automated PR review bot.
* Bug Fixed: Anonymous recursive types in wrappers were creating dangling references.
Root Cause: When a named type (like SchemaRoot) was already in progress or existed in definitions, the code was incorrectly deleting it from the
definitionStack at line 188-190. This broke cycle detection for any child types being formatted, because the parent type was no longer on the stack
to detect the cycle.
The Fix: Removed the incorrect definitionStack.delete() call at lines 188-190. This deletion was logically wrong because:
1. We never pushed to the stack at that point (we return early before line 210's push)
2. If something with that key WAS on the stack, it was from a parent call, and deleting it broke cycle detection
Test Updates:
- Updated anonymous-recursive-wrapper.expected.json to reflect the correct behavior: anonymous objects that appear only once should be inlined, not
hoisted to separate definitions
- The test now passes with the schema correctly inlining the anonymous object and using for SchemaRoot's cycle
* fix(schema-generator): handle wrapper type aliases with generic parameters
Fixes improper type extraction from wrapper alias declarations that contain
generic type parameters instead of concrete types.
When processing wrapper aliases like 'type MyCell<T> = Cell<T>' or nested
aliases like 'Cell<NumberList<number>>' where 'NumberList<T> = T[]', the
code was incorrectly extracting type information from alias declarations
(which contain generic 'T') instead of from usage sites (which have
concrete types like 'string' or 'number').
Key changes:
- Filter out type parameter nodes in wrapper and array formatters by checking
if extracted types have TypeFlags.TypeParameter flag
- Fix formatChildType to properly clear parent typeNode context using
destructuring, preventing mismatched type/node pairs in recursive calls
- Improve Default wrapper node selection to prefer usage-site nodes with
concrete type arguments over alias declaration nodes
- Update wrapper-aliases test fixture to use realistic interface definitions
matching actual CommonTools wrappers instead of simple type erasure
Before: 'Cell<NumberList<number>>' generated 'items: {}' (empty object)
After: 'Cell<NumberList<number>>' generates 'items: { type: number }'
Related to commit 16aceaf which fixed anonymous recursive wrapper refs.
* fmt, lint
* update fixture expectation for new improved behavior
* fix fixture
0 commit comments