Problem
When a type includes keyof T (e.g., keyof React.JSX.IntrinsicElements), the extractor eagerly resolves it into the full union of string literals. For IntrinsicElements, this produces 200+ members:
'symbol' | 'object' | 'a' | 'abbr' | 'address' | 'area' | 'article' | 'aside' | 'audio' | 'b' | 'base' | ...
This makes the extracted type data very large and hard to read in documentation.
Example
Source:
interface Parameters {
defaultTagName?: keyof React.JSX.IntrinsicElements;
}Current output (simplified): a UnionNode with 200+ literal members and no typeName.
Expected: ideally preserve keyof React.JSX.IntrinsicElements as a recognizable type reference (e.g., via typeName or a dedicated keyof node kind), so downstream consumers can decide whether to expand or display the compact form.
Context
This came up while generating API documentation for Base UI's useRender hook. The defaultTagName property's type gets fully expanded in the docs, producing hundreds of lines of string literal union members. Downstream tools have no way to detect that this was originally a keyof expression and collapse it back.
Problem
When a type includes
keyof T(e.g.,keyof React.JSX.IntrinsicElements), the extractor eagerly resolves it into the full union of string literals. ForIntrinsicElements, this produces 200+ members:This makes the extracted type data very large and hard to read in documentation.
Example
Source:
Current output (simplified): a
UnionNodewith 200+ literal members and notypeName.Expected: ideally preserve
keyof React.JSX.IntrinsicElementsas a recognizable type reference (e.g., viatypeNameor a dedicatedkeyofnode kind), so downstream consumers can decide whether to expand or display the compact form.Context
This came up while generating API documentation for Base UI's
useRenderhook. ThedefaultTagNameproperty's type gets fully expanded in the docs, producing hundreds of lines of string literal union members. Downstream tools have no way to detect that this was originally akeyofexpression and collapse it back.