Summary
After the ADR-0004 Box type migration, MetaMask Mobile hit TypeScript failures when consumer wrapper components extended BoxProps and then forwarded those props into <Box {...props} />.
The failure appears when the consumer dependency graph still exposes older @types/react-native callback types while @metamask/design-system-react-native resolves React Native 0.76 bundled types.
Repro shape
A minimal consumer-side pattern that can fail:
import { Box, BoxProps } from '@metamask/design-system-react-native';
interface WrapperProps extends Omit<BoxProps, 'children'> {}
export const Wrapper = (props: WrapperProps) => <Box {...props} />;
In MetaMask Mobile this surfaced most clearly on onLayout, where TS compared:
@types/react-native LayoutChangeEvent
- vs React Native bundled
LayoutChangeEvent
The JSX spread then failed even though BoxProps looks structurally correct.
Observed behavior
In MetaMask Mobile:
BoxProps in forwarding wrappers can fail TS checks on native callback props like onLayout
React.ComponentProps<typeof Box> works reliably because it matches the actual JSX contract of the concrete Box component
- Removing/hiding
node_modules/@types/react-native in a local repro made the HeaderSearch onLayout mismatch disappear
Why this matters
Mobile is temporarily using React.ComponentProps<typeof Box> in forwarding wrappers to unblock the stable design-system release pipeline, but this is a consumer-side workaround. We should decide whether MMDS can provide a clearer or safer library-side path.
Questions to resolve
- Is the root cause entirely consumer-side mixed RN type identity, or does the exported
BoxProps alias shape contribute?
- Should MMDS explicitly document that forwarding wrappers should prefer
React.ComponentProps<typeof Box> over BoxProps?
- Should MMDS export an official wrapper-safe alias such as
BoxComponentProps?
- Can emitted declarations or package typing strategy be improved to reduce this mismatch for consumers still carrying DT React Native packages?
Suggested acceptance criteria
- Reproduce the issue in a small consumer fixture
- Confirm whether mixed RN type sources are sufficient to trigger it
- Decide on the recommended library guidance and/or exported type surface
- Document the intended consumer pattern for forwarding wrappers
Related context
Summary
After the ADR-0004 Box type migration, MetaMask Mobile hit TypeScript failures when consumer wrapper components extended
BoxPropsand then forwarded those props into<Box {...props} />.The failure appears when the consumer dependency graph still exposes older
@types/react-nativecallback types while@metamask/design-system-react-nativeresolves React Native 0.76 bundled types.Repro shape
A minimal consumer-side pattern that can fail:
In MetaMask Mobile this surfaced most clearly on
onLayout, where TS compared:@types/react-nativeLayoutChangeEventLayoutChangeEventThe JSX spread then failed even though
BoxPropslooks structurally correct.Observed behavior
In MetaMask Mobile:
BoxPropsin forwarding wrappers can fail TS checks on native callback props likeonLayoutReact.ComponentProps<typeof Box>works reliably because it matches the actual JSX contract of the concreteBoxcomponentnode_modules/@types/react-nativein a local repro made theHeaderSearchonLayoutmismatch disappearWhy this matters
Mobile is temporarily using
React.ComponentProps<typeof Box>in forwarding wrappers to unblock the stable design-system release pipeline, but this is a consumer-side workaround. We should decide whether MMDS can provide a clearer or safer library-side path.Questions to resolve
BoxPropsalias shape contribute?React.ComponentProps<typeof Box>overBoxProps?BoxComponentProps?Suggested acceptance criteria
Related context
Box