typescript strictness cleanup#770
Merged
rohanchkrabrty merged 5 commits intomainfrom May 5, 2026
Merged
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
Contributor
|
Caution Review failedPull request was closed or merged during review 📝 WalkthroughWalkthroughThis pull request systematically improves TypeScript type safety across the codebase by replacing permissive Possibly related issues
Suggested reviewers
🚥 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. Tip 💬 Introducing Slack Agent: The best way for teams to turn conversations into code.Slack Agent is built on CodeRabbit's deep understanding of your code, so your team can collaborate across the entire SDLC without losing context.
Built for teams:
One agent for your entire SDLC. Right inside Slack. 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 |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
🧹 Nitpick comments (1)
packages/raystack/components/select/select-root.tsx (1)
219-220: ⚡ Quick winInconsistency:
@ts-ignorewas not converted to@ts-expect-errorunlike every other suppression in this PR.The upstream
@base-ui/reactissue is confirmed:autoHighlightis publicly typed asbooleanonly, which causes valid runtime usage ofautoHighlight="always"to fail type-checking. The comment is now accurate and useful, but the directive itself should be upgraded for consistency and automatic cleanup once the upstream fix lands.Using
@ts-expect-errorinstead of@ts-ignoremeans TypeScript will emit an "Unused '@ts-expect-error' directive" warning when@base-ui/reactcorrects its types (tracked in their GitHub issue#4188), prompting removal of the suppression without manual tracking.♻️ Proposed change
- // `@ts-ignore` `@base-ui/react`@1.3.0 ComboboxRootProps types `autoHighlight` as `boolean | undefined`, but the runtime accepts `always | input-change`. Remove when upstream types are corrected. + // `@ts-expect-error` `@base-ui/react`@1.3.0 ComboboxRootProps types `autoHighlight` as `boolean | undefined`, but the runtime accepts `always | input-change`. Remove when upstream types are corrected. autoHighlight='always'🤖 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/raystack/components/select/select-root.tsx` around lines 219 - 220, Replace the TypeScript suppression above the autoHighlight prop in select-root.tsx: change the existing "@ts-ignore" directive to "@ts-expect-error" for the ComboboxRootProps/autoHighlight usage (autoHighlight='always') so the suppression will produce an unused-directive warning once `@base-ui/react` fixes its types; keep the existing explanatory comment referencing ComboboxRootProps and the upstream issue.
🤖 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.
Nitpick comments:
In `@packages/raystack/components/select/select-root.tsx`:
- Around line 219-220: Replace the TypeScript suppression above the
autoHighlight prop in select-root.tsx: change the existing "@ts-ignore"
directive to "@ts-expect-error" for the ComboboxRootProps/autoHighlight usage
(autoHighlight='always') so the suppression will produce an unused-directive
warning once `@base-ui/react` fixes its types; keep the existing explanatory
comment referencing ComboboxRootProps and the upstream issue.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: df123a7d-cf07-4411-9e96-3f95c10a90cf
📒 Files selected for processing (7)
apps/www/src/components/mdx/mdx-components.tsxapps/www/src/lib/prettier.tsapps/www/src/types/prettier.d.tspackages/raystack/components/amount/__tests__/amount.test.tsxpackages/raystack/components/amount/amount.tsxpackages/raystack/components/select/select-root.tsxpackages/raystack/components/theme-provider/theme.tsx
💤 Files with no reviewable changes (1)
- apps/www/src/lib/prettier.ts
rohanchkrabrty
requested changes
May 5, 2026
Contributor
There was a problem hiding this comment.
Actionable comments posted: 4
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (2)
apps/www/src/content/docs/components/checkbox/demo.ts (1)
6-10:⚠️ Potential issue | 🟠 Major | ⚡ Quick winAvoid mutating the incoming
propsobject ingetCode.
getCodecurrently mutatesprops.checked, which can leak side effects back to caller state and make playground behavior non-deterministic. Normalize into a local object instead.Suggested fix
export const getCode = (props: ComponentPropsType) => { - if (props.checked === 'false') props.checked = false; - else if (props.checked === 'true') props.checked = true; - - return `<Checkbox${getPropsString(props)}/>`; + const normalizedProps = { + ...props, + checked: + props.checked === 'false' + ? false + : props.checked === 'true' + ? true + : props.checked + }; + + return `<Checkbox${getPropsString(normalizedProps)}/>`; };🤖 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 `@apps/www/src/content/docs/components/checkbox/demo.ts` around lines 6 - 10, getCode is mutating the incoming props by reassigning props.checked; instead create a local copy (e.g., const localProps = { ...props }) and normalize localProps.checked from string to boolean, then pass localProps into getPropsString; this preserves the original props object and prevents side effects from getCode while keeping the same output logic.apps/www/src/app/examples/table/page.tsx (1)
108-108:⚠️ Potential issue | 🟡 Minor | ⚡ Quick winRemove debug
console.logbefore merging.🧹 Proposed fix
- console.log('tableQuery>> ', tableQuery);🤖 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 `@apps/www/src/app/examples/table/page.tsx` at line 108, Remove the debug console.log in apps/www/src/app/examples/table/page.tsx that prints "tableQuery>> " and tableQuery; specifically delete the console.log statement that references tableQuery (used for debugging) so no debug output remains in the production page component or module.
🧹 Nitpick comments (7)
apps/www/src/content/docs/components/slider/props.ts (1)
42-42: 💤 Low value
eventDetails: unknownloses documentation accuracy.The Base UI Slider's
onValueChangeevent details parameter has a concrete type (e.g.Slider.Root.ChangeEventDetails). Usingunknownhere means users reading the generated docs table won't know the shape ofeventDetails. Consider importing and using the concrete type, or at least adding a@remarksJSDoc with the expected shape.🤖 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 `@apps/www/src/content/docs/components/slider/props.ts` at line 42, The onValueChange prop currently types its second parameter as unknown which hides the real event shape from docs; update the onValueChange signature in props.ts to use the concrete event-details type from the slider library (e.g. import and use Slider.Root.ChangeEventDetails or the exact exported ChangeEventDetails type) so generated docs show the true shape, or if importing isn’t possible, add a JSDoc `@remarks` on onValueChange describing the expected event-details shape (reference the onValueChange declaration in props.ts to locate the change).packages/raystack/components/data-table/data-table.types.tsx (1)
23-29: ⚖️ Poor tradeoff
value: unknownis the right direction, but the sibling fields create an awkward API.
DataTableFilterValuesnow has bothvalue: unknownand three typed optional fields (boolValue?,stringValue?,numberValue?) with a comment saying only one should be present at a time. Ifvalueis the generic holder and the typed fields are the narrowed alternatives, consider whethervalueis still needed, or whether thestring | boolean | number | unknownunion should be expressed more explicitly. The current shape allowsvalueto silently hold anything that the sibling typed fields can't express.This is a broader API design concern — not a blocker for this PR — but worth tracking as a follow-up.
🤖 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/raystack/components/data-table/data-table.types.tsx` around lines 23 - 29, The DataTableFilterValues type mixes a generic value: unknown with sibling typed option fields (boolValue, stringValue, numberValue) which allows inconsistent states; update the type to be a clear discriminated union or remove the generic value field so only one typed variant can exist—e.g., replace DataTableFilterValues with a union of { type: 'boolean', value: boolean } | { type: 'string', value: string } | { type: 'number', value: number } (or make value: string | boolean | number explicitly) so consumers cannot populate value with something outside the typed alternatives and only one variant is allowed at a time.apps/www/src/content/docs/components/popover/props.ts (1)
44-46: 💤 Low value
(props: unknown, state: unknown)is less accurate than the Base UI concrete types.The Base UI Popup
rendercallback signature is(props: HTMLProps, state: Popup.State) => ReactElement. Usingunknownmakes this documentation interface less informative than the actual API — readers looking at the generated props table won't know what shapepropsorstatehave. Consider using the concrete Base UI types, or at a minimum documenting the actual shapes in a JSDoc remark.🤖 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 `@apps/www/src/content/docs/components/popover/props.ts` around lines 44 - 46, The render? prop is typed too loosely with (props: unknown, state: unknown); update it to use the Base UI concrete types so consumers see the real API shape — replace the unknowns with the correct Base Web types (e.g., HTMLProps for props and Popup.State for state) on the render signature in props.ts (and add the corresponding import or a JSDoc reference to the Base UI Popup types if imports are not desired) so the generated docs show accurate shapes.packages/raystack/components/command/command-root.tsx (1)
34-44: ⚡ Quick winMake
CommandRootPropsgeneric to preserve typed callback inference.With
AutocompletePrimitive.Root.Props<unknown>, all inherited item-typed callbacks (e.g.filter,itemToStringValue,getItemLabel) will expect(item: unknown) => .... Under TypeScript's strict function type rules (contravariance), passing a callback with a narrower type—such asfilter={(item: MyItem) => item.name.includes(query)}—will produce a type error, because(MyItem) => booleanis not assignable to(unknown) => boolean.A generic
TonCommandRootPropspreserves the inference chain and allows callers to pass properly typed callbacks:♻️ Proposed fix
-export interface CommandRootProps - extends Omit<AutocompletePrimitive.Root.Props<unknown>, 'items'> { +export interface CommandRootProps<T = unknown> + extends Omit<AutocompletePrimitive.Root.Props<T>, 'items'> { /** * Items to be displayed and filtered by Base UI internally. * ... */ - items?: readonly unknown[]; + items?: readonly T[]; /** Additional CSS class for the panel wrapper. */ className?: string; }Then update
CommandRoottoCommandRoot<T = unknown>({ ... }: CommandRootProps<T>). Callers passingitems={myTypedArray}will haveTinferred automatically.🤖 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/raystack/components/command/command-root.tsx` around lines 34 - 44, Make CommandRootProps generic so typed callbacks keep inference: change CommandRootProps to accept a type parameter T (e.g., CommandRootProps<T = unknown>) and extend Omit<AutocompletePrimitive.Root.Props<T>, 'items'>, then update the CommandRoot component signature to CommandRoot<T = unknown>({ ... }: CommandRootProps<T>) so passing items={myTypedArray} infers T and preserves the correct types for callbacks like filter, itemToStringValue, and getItemLabel.apps/www/src/content/docs/components/tooltip/demo.ts (1)
6-16: 💤 Low value
unknownvalues interpolated directly into template literals may triggerrestrict-template-expressions.After the
any→ComponentPropsTypeswitch,childrenandtrackCursorAxisdestructured fromRecord<string, unknown>are typed asunknown. TypeScript itself won't error, but@typescript-eslint/restrict-template-expressions(enabled inrecommended-type-checked) will flag${children}and${trackCursorAxis}as invalid interpolation targets.♻️ Proposed fix – narrow via `String()`
export const getCode = (props: ComponentPropsType) => { - const { children = 'Tooltip message', trackCursorAxis, ...rest } = props; + const { children = 'Tooltip message', trackCursorAxis, ...rest } = props; + const childrenStr = String(children); + const axisStr = typeof trackCursorAxis === 'string' ? trackCursorAxis : ''; return ` <Tooltip ${trackCursorAxis ? `trackCursorAxis="${axisStr}"` : ''}> <Tooltip.Trigger render={<Button />}> Hover me </Tooltip.Trigger> <Tooltip.Content ${getPropsString(rest)}> - ${children} + ${childrenStr} </Tooltip.Content> </Tooltip>`; };🤖 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 `@apps/www/src/content/docs/components/tooltip/demo.ts` around lines 6 - 16, The template interpolates values typed as unknown (destructured from ComponentPropsType) causing restrict-template-expressions errors; update getCode to coerce those values before interpolation—use String(children) for the content interpolation and String(trackCursorAxis) (or conditionally include the attribute only when defined) for the Tooltip attribute, and keep using getPropsString(rest) unchanged so TypeScript-eslint no longer flags ${children} and ${trackCursorAxis}.apps/www/src/content/docs/components/link/demo.ts (1)
6-9: 💤 Low valueSame
unknown-in-template-literal concern introduced by switching fromany.
childrendestructured fromRecord<string, unknown>is typedunknown. Using it in${children}can trigger@typescript-eslint/restrict-template-expressionsif enabled. A simpleString(children)cast resolves it.♻️ Proposed fix
export const getCode = (props: ComponentPropsType) => { const { children, ...rest } = props; - return `<Link${getPropsString(rest)}>${children}</Link>`; + return `<Link${getPropsString(rest)}>${String(children)}</Link>`; };🤖 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 `@apps/www/src/content/docs/components/link/demo.ts` around lines 6 - 9, In getCode, children is coming from ComponentPropsType as unknown so interpolating `${children}` may violate restrict-template-expressions; convert it to a string before embedding (e.g. use String(children)) when building the template literal returned by getCode so the call to getPropsString(rest) remains unchanged and the template interpolation is safe.packages/raystack/components/data-table/utils/__tests__/index.test.tsx (1)
425-426: 💤 Low value
never[]cast is technically valid butunknown[]is more idiomatic for null/undefined boundary tests.
never[]is the bottom array type (no values can exist), which is more confusing than necessary for this use case.♻️ Proposed change
- expect(groupData(null as unknown as never[])).toEqual([]); - expect(groupData(undefined as unknown as never[])).toEqual([]); + expect(groupData(null as unknown as unknown[])).toEqual([]); + expect(groupData(undefined as unknown as unknown[])).toEqual([]);🤖 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/raystack/components/data-table/utils/__tests__/index.test.tsx` around lines 425 - 426, The test uses the bottom type never[] when passing null/undefined to groupData which is confusing; update the two expectations to cast null and undefined to unknown[] instead (i.e., replace null as unknown as never[] and undefined as unknown as never[] with null as unknown as unknown[] and undefined as unknown as unknown[] or simply null as unknown[] / undefined as unknown[]), keeping the calls to groupData(...) and expected [] unchanged so the test still verifies the null/undefined boundary for the groupData function.
🤖 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 `@apps/www/src/app/examples/table/page.tsx`:
- Around line 126-128: The current shouldShow expression calls .includes on
tableQuery?.filters?.[filters.indexOf('status')]?.value cast to string[] which
can be undefined at runtime; change the shouldShow calculation in page.tsx to
guard the status filter value by falling back to an empty array before calling
includes (e.g., derive a safeStatusArray from
tableQuery?.filters?.[filters.indexOf('status')]?.value and default to []), then
call includes(item.status) on that safe array so .includes is never invoked on
undefined; keep references to shouldShow, tableQuery, filters and item.status
when locating the code to update.
In `@apps/www/src/content/docs/components/amount/demo.ts`:
- Around line 6-8: The getCode function contains a leftover debug side-effect:
remove the console.log('props:', props) call from getCode so it no longer logs
props during normal docs rendering; keep the return that uses
getPropsString(props) unchanged.
In `@apps/www/src/content/docs/components/tabs/props.ts`:
- Line 9: Change the onValueChange callback signature from accepting unknown to
accepting string (or any) so consumers with explicit parameter types can pass
(v: string) handlers without TS errors; update the onValueChange?: (value:
unknown) => void declaration in props.ts (the Tabs props interface used by
Tabs.Root/Tabs components) to onValueChange?: (value: string) => void (or any)
to match runtime behavior and satisfy strictFunctionTypes.
In `@packages/raystack/components/data-table/components/filters.tsx`:
- Around line 140-141: Update FilterChip's value prop type to accept the actual
union used by filters (use the existing FilterPrimitive from
filter-operations.tsx or string | string[] | Date) instead of a plain string,
remove the "as string" cast at the call site (the value={filter.value as string}
usage in components/filters.tsx), and import/align the prop type with
FilterPrimitive so all callers pass filter.value directly without type
assertions; also update any FilterChip internals that assume value is always a
string to branch on string | string[] | Date as needed.
---
Outside diff comments:
In `@apps/www/src/app/examples/table/page.tsx`:
- Line 108: Remove the debug console.log in
apps/www/src/app/examples/table/page.tsx that prints "tableQuery>> " and
tableQuery; specifically delete the console.log statement that references
tableQuery (used for debugging) so no debug output remains in the production
page component or module.
In `@apps/www/src/content/docs/components/checkbox/demo.ts`:
- Around line 6-10: getCode is mutating the incoming props by reassigning
props.checked; instead create a local copy (e.g., const localProps = { ...props
}) and normalize localProps.checked from string to boolean, then pass localProps
into getPropsString; this preserves the original props object and prevents side
effects from getCode while keeping the same output logic.
---
Nitpick comments:
In `@apps/www/src/content/docs/components/link/demo.ts`:
- Around line 6-9: In getCode, children is coming from ComponentPropsType as
unknown so interpolating `${children}` may violate
restrict-template-expressions; convert it to a string before embedding (e.g. use
String(children)) when building the template literal returned by getCode so the
call to getPropsString(rest) remains unchanged and the template interpolation is
safe.
In `@apps/www/src/content/docs/components/popover/props.ts`:
- Around line 44-46: The render? prop is typed too loosely with (props: unknown,
state: unknown); update it to use the Base UI concrete types so consumers see
the real API shape — replace the unknowns with the correct Base Web types (e.g.,
HTMLProps for props and Popup.State for state) on the render signature in
props.ts (and add the corresponding import or a JSDoc reference to the Base UI
Popup types if imports are not desired) so the generated docs show accurate
shapes.
In `@apps/www/src/content/docs/components/slider/props.ts`:
- Line 42: The onValueChange prop currently types its second parameter as
unknown which hides the real event shape from docs; update the onValueChange
signature in props.ts to use the concrete event-details type from the slider
library (e.g. import and use Slider.Root.ChangeEventDetails or the exact
exported ChangeEventDetails type) so generated docs show the true shape, or if
importing isn’t possible, add a JSDoc `@remarks` on onValueChange describing the
expected event-details shape (reference the onValueChange declaration in
props.ts to locate the change).
In `@apps/www/src/content/docs/components/tooltip/demo.ts`:
- Around line 6-16: The template interpolates values typed as unknown
(destructured from ComponentPropsType) causing restrict-template-expressions
errors; update getCode to coerce those values before interpolation—use
String(children) for the content interpolation and String(trackCursorAxis) (or
conditionally include the attribute only when defined) for the Tooltip
attribute, and keep using getPropsString(rest) unchanged so TypeScript-eslint no
longer flags ${children} and ${trackCursorAxis}.
In `@packages/raystack/components/command/command-root.tsx`:
- Around line 34-44: Make CommandRootProps generic so typed callbacks keep
inference: change CommandRootProps to accept a type parameter T (e.g.,
CommandRootProps<T = unknown>) and extend
Omit<AutocompletePrimitive.Root.Props<T>, 'items'>, then update the CommandRoot
component signature to CommandRoot<T = unknown>({ ... }: CommandRootProps<T>) so
passing items={myTypedArray} infers T and preserves the correct types for
callbacks like filter, itemToStringValue, and getItemLabel.
In `@packages/raystack/components/data-table/data-table.types.tsx`:
- Around line 23-29: The DataTableFilterValues type mixes a generic value:
unknown with sibling typed option fields (boolValue, stringValue, numberValue)
which allows inconsistent states; update the type to be a clear discriminated
union or remove the generic value field so only one typed variant can
exist—e.g., replace DataTableFilterValues with a union of { type: 'boolean',
value: boolean } | { type: 'string', value: string } | { type: 'number', value:
number } (or make value: string | boolean | number explicitly) so consumers
cannot populate value with something outside the typed alternatives and only one
variant is allowed at a time.
In `@packages/raystack/components/data-table/utils/__tests__/index.test.tsx`:
- Around line 425-426: The test uses the bottom type never[] when passing
null/undefined to groupData which is confusing; update the two expectations to
cast null and undefined to unknown[] instead (i.e., replace null as unknown as
never[] and undefined as unknown as never[] with null as unknown as unknown[]
and undefined as unknown as unknown[] or simply null as unknown[] / undefined as
unknown[]), keeping the calls to groupData(...) and expected [] unchanged so the
test still verifies the null/undefined boundary for the groupData function.
🪄 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: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: cb1770dd-cb92-4f3b-b627-722b9795bde1
📒 Files selected for processing (72)
apps/www/src/app/examples/table/page.tsxapps/www/src/components/demo/types.tsapps/www/src/components/icon-details/icon-details.tsxapps/www/src/content/docs/components/accordion/demo.tsapps/www/src/content/docs/components/amount/demo.tsapps/www/src/content/docs/components/announcement-bar/demo.tsapps/www/src/content/docs/components/avatar/demo.tsapps/www/src/content/docs/components/badge/demo.tsapps/www/src/content/docs/components/breadcrumb/demo.tsapps/www/src/content/docs/components/button/demo.tsapps/www/src/content/docs/components/callout/demo.tsapps/www/src/content/docs/components/checkbox/demo.tsapps/www/src/content/docs/components/chip/demo.tsapps/www/src/content/docs/components/code-block/demo.tsapps/www/src/content/docs/components/combobox/demo.tsapps/www/src/content/docs/components/container/demo.tsapps/www/src/content/docs/components/context-menu/demo.tsapps/www/src/content/docs/components/copy-button/demo.tsapps/www/src/content/docs/components/datatable/props.tsapps/www/src/content/docs/components/drawer/demo.tsapps/www/src/content/docs/components/empty-state/demo.tsapps/www/src/content/docs/components/field/demo.tsapps/www/src/content/docs/components/filter-chip/demo.tsapps/www/src/content/docs/components/flex/demo.tsapps/www/src/content/docs/components/form/props.tsapps/www/src/content/docs/components/grid/demo.tsapps/www/src/content/docs/components/headline/demo.tsapps/www/src/content/docs/components/icon-button/demo.tsapps/www/src/content/docs/components/image/demo.tsapps/www/src/content/docs/components/indicator/demo.tsapps/www/src/content/docs/components/input/demo.tsapps/www/src/content/docs/components/label/demo.tsapps/www/src/content/docs/components/link/demo.tsapps/www/src/content/docs/components/menu/demo.tsapps/www/src/content/docs/components/meter/demo.tsapps/www/src/content/docs/components/number-field/demo.tsapps/www/src/content/docs/components/popover/demo.tsapps/www/src/content/docs/components/popover/props.tsapps/www/src/content/docs/components/preview-card/demo.tsapps/www/src/content/docs/components/progress/demo.tsapps/www/src/content/docs/components/radio/demo.tsapps/www/src/content/docs/components/radio/props.tsapps/www/src/content/docs/components/scroll-area/demo.tsapps/www/src/content/docs/components/search/demo.tsapps/www/src/content/docs/components/select/demo.tsapps/www/src/content/docs/components/select/props.tsapps/www/src/content/docs/components/separator/demo.tsapps/www/src/content/docs/components/skeleton/demo.tsapps/www/src/content/docs/components/slider/demo.tsapps/www/src/content/docs/components/slider/props.tsapps/www/src/content/docs/components/spinner/demo.tsapps/www/src/content/docs/components/switch/demo.tsapps/www/src/content/docs/components/tabs/props.tsapps/www/src/content/docs/components/text/demo.tsapps/www/src/content/docs/components/textarea/demo.tsapps/www/src/content/docs/components/toggle/demo.tsapps/www/src/content/docs/components/tooltip/demo.tsapps/www/src/lib/remark.tsapps/www/src/lib/utils.tspackages/raystack/CHANGELOG.mdpackages/raystack/components/alert-dialog/__tests__/alert-dialog.test.tsxpackages/raystack/components/avatar/__tests__/avatar.test.tsxpackages/raystack/components/command/command-root.tsxpackages/raystack/components/data-table/components/filters.tsxpackages/raystack/components/data-table/data-table.types.tsxpackages/raystack/components/data-table/hooks/useFilters.tsxpackages/raystack/components/data-table/utils/__tests__/filter-operations.test.tsxpackages/raystack/components/data-table/utils/__tests__/index.test.tsxpackages/raystack/components/data-table/utils/filter-operations.tsxpackages/raystack/components/data-table/utils/index.tsxpackages/raystack/components/dialog/__tests__/dialog.test.tsxpackages/raystack/hooks/useDebouncedState.tsx
✅ Files skipped from review due to trivial changes (16)
- packages/raystack/components/alert-dialog/tests/alert-dialog.test.tsx
- packages/raystack/components/data-table/utils/tests/filter-operations.test.tsx
- apps/www/src/content/docs/components/switch/demo.ts
- apps/www/src/content/docs/components/announcement-bar/demo.ts
- apps/www/src/content/docs/components/grid/demo.ts
- packages/raystack/CHANGELOG.md
- packages/raystack/components/data-table/hooks/useFilters.tsx
- apps/www/src/content/docs/components/flex/demo.ts
- apps/www/src/content/docs/components/empty-state/demo.ts
- packages/raystack/components/avatar/tests/avatar.test.tsx
- apps/www/src/content/docs/components/menu/demo.ts
- apps/www/src/content/docs/components/toggle/demo.ts
- apps/www/src/content/docs/components/progress/demo.ts
- apps/www/src/lib/utils.ts
- apps/www/src/content/docs/components/callout/demo.ts
- apps/www/src/content/docs/components/code-block/demo.ts
paanSinghCoder
approved these changes
May 5, 2026
rohanchkrabrty
requested changes
May 5, 2026
Shreyag02
changed the title
rohanchkrabrty
approved these changes
May 5, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
Cleanup pass that strengthens type-safety across the design system and the docs site without changing runtime behavior in production code paths.
Three layers of work:
with proper APIs / @ts-expect-error (where the upstream type gap is real).
files, and tests. New types added where needed: FilterPrimitive union, MdxJsxFlowElementLike interface, ComponentPropsType reuse.
Notable correctness improvements (latent bug fixes, not regressions):
so
<h1>–<h6>render as the correct semantic tags. Previously rendered as<h2>/<span>with a stray as="hN" HTML attribute.Tooling cleanup:
Type of Change
How Has This Been Tested?
56/54). The 2-error drop in apps/www comes from the mdx-components.tsx render prop fix clearing 6 @ts-expect-error suppressions.
deliberately-kept any in filter-chip.tsx).
test code asserting deliberately-invalid input.
Checklist:
Screenshots (if appropriate):
N/A — no UI changes. The mdx-components.tsx render prop fix changes the rendered HTML tag from
<h2>/<span>to<h1>–<h6>for semanticcorrectness; visual styling stays identical because it's driven by the size prop, not the tag name.
Related Issues
#675