deprecated-react-native-prop-types

deprecated-react-native-prop-types packages up the prop-types definitions that were once built into React Native’s core components — View, Text, Image, TextInput, and more — after the framework moved away from PropTypes-based validation. Rather than forcing every legacy codebase to rewrite its component contracts overnight, the package re-exports the exact same ColorPropType, EdgeInsetsPropType, ImagePropTypes, PointPropType, TextInputPropTypes, TextPropTypes, and ViewPropTypes objects that react-native used to expose directly, so a one-line import swap is usually all that’s needed to keep older, PropTypes-reliant components compiling.

It is maintained by Meta alongside a handful of sibling deprecated-* packages (deprecated-react-native-listview, deprecated-react-native-swipeablelistview, deprecated-react-native-ios-mapview, deprecated-react-native-ios-adsupport) in the same react-native-deprecated-modules repository, each following the same pattern: extract a module React Native removed from core, publish it standalone, and let teams migrate on their own timeline.

What You Get

• ViewPropTypes & DeprecatedViewPropTypes - the full prop-types shape for View, including accessibility, gesture-responder, mouse, pointer, and focus event props, matching what React Native used to expose on View.propTypes.
• Text and TextInput prop-types - TextPropTypes and TextInputPropTypes covering the complete set of style and behavior props those components accepted before PropTypes were dropped.
• Image-related prop-types - ImagePropTypes, ImageStylePropTypes, and ImageSourcePropType for validating image component props and source objects.
• Shared shape helpers - ColorPropType, EdgeInsetsPropType, PointPropType, and a StyleSheetPropType factory that other prop-type definitions compose from, so custom components can reuse the same primitives.
• Lazy-loaded exports - every export in index.js is a getter that only requires its backing module on first access, so unused prop-type definitions are never evaluated.

Common Use Cases

• Migrating off Component.propTypes gradually - a team upgrading React Native keeps components that still rely on ViewPropTypes/TextPropTypes working by importing them from this package instead of react-native directly.
• Maintaining older React Native libraries - a third-party component library that exposes PropTypes-based prop validation on its own components depends on this package instead of pinning to an old React Native version.
• Building custom components with the same shape validators - a custom View-like component reuses DeprecatedEdgeInsetsPropType or DeprecatedStyleSheetPropType to keep prop validation consistent with core React Native components.
• Auditing legacy prop usage before a TypeScript/Flow migration - teams import the deprecated prop-types temporarily to keep builds green while incrementally converting components to typed props.

Under The Hood

Architecture deprecated-react-native-prop-types is architected as a flat, tree-shakeable namespace rather than a layered application: index.js exposes seven named exports through lazy getters that require() their backing module only on first access, avoiding unnecessary evaluation of unused prop-type definitions. Each Deprecated*PropTypes.js file (DeprecatedViewPropTypes.js, DeprecatedTextPropTypes.js, DeprecatedImagePropTypes.js, and others) is a self-contained module exporting a plain object built from prop-types validators, composed via object-spread from smaller shared fragments (MouseEventPropTypes, PointerEventPropTypes, FocusEventPropTypes, TouchEventPropTypes, GestureResponderEventPropTypes inside DeprecatedViewPropTypes.js) and cross-referencing sibling modules like DeprecatedEdgeInsetsPropType.js, DeprecatedStyleSheetPropType.js, and DeprecatedViewAccessibility.js for shared shape definitions. There is no runtime logic, class hierarchy, or dependency injection — the entire package is a static, declarative catalogue of PropTypes.shape()/oneOfType() definitions, so changing a core abstraction like DeprecatedEdgeInsetsPropType only ripples into the handful of sibling files that explicitly require it.

Tech Stack The package targets plain CommonJS JavaScript annotated with Flow (@flow pragma) rather than TypeScript, and ships no build step — the files are consumed as-is by Node/Metro without a bundler or transpiler config present in this scoped package directory. Its only runtime dependencies are prop-types for the validator primitives, invariant for assertion helpers, and @react-native/normalize-colors for the color normalization used by DeprecatedColorPropType.js; engines.node >=18 has been enforced explicitly since the 5.0.0 release. There is no database, server, or deployment target — it is a pure library published to npm and consumed by importing React Native applications.

Code Quality Test coverage is effectively absent: the package’s only test script is node -e "Object.values(require('.'))", which merely confirms every lazy-getter export resolves without throwing — it does not assert on the shape or correctness of any individual PropTypes definition, and no dedicated test files exist in the package directory. No ESLint or Flow config is checked into this scoped subdirectory of the monorepo, and no CI workflow file was found in the cloned repository, so any quality enforcement is inherited from the parent react-native monorepo rather than being visible here. Naming is consistent and predictable (DeprecatedXPropType(s) mirrors the removed React Native API it replaces), and every file carries a standard copyright/license header, but there is no type-safety beyond the Flow pragma comment and no runtime validation tests.

What Makes It Unique This package makes no novel technical contribution — it is explicitly a compatibility shim that re-exports prop-types objects that were removed from React Native’s core so codebases relying on Component.propTypes can continue to function without a hard break. Its one design choice worth noting is the lazy-getter pattern in index.js, which avoids importing prop-types validators an application doesn’t use — a modest tree-shaking-adjacent optimization, not an architectural innovation. It doesn’t compete with alternatives because it exists purely to bridge a deprecation, not to solve a novel problem.