[0.80] Deprecating deep imports from react-native — Feedback thread

[huntie]

Introduction

See the RFC | See the 0.80 release post

🚨 Key change: In React Native 0.80, we are deprecating subpath imports (or "deep imports") from the react-native npm package.

By defining a clear, root-level JavaScript API contract, we aim to minimise future React Native breaking changes and improve long-term predictability for the ecosystem.

// Before - subpath imports allowed
import {Alert, AlertType} from 'react-native/Libraries/Alert/Alert';

// After - must import from 'react-native'
import {Alert, AlertType} from 'react-native';

Why it matters: While initially deprecated with warnings, we aim to remove these import paths entirely, which will be a breaking change.

This discussion thread

Please raise issues/questions about APIs you are using that are affected by this change. Over our API consultation period (beginning 0.80), we'll evaluate requests for exposing new APIs at the root, or providing alternatives.

Planned sequencing

• React Native 0.80: Deprecation of subpath imports, introduce runtime warnings.
• React Native 0.82 (or later): Removal of subpath imports via "exports" and the Strict TypeScript API.

What we've actioned!

https://github.com/facebook/react-native/issues?q=sort%3Acreated-desc%20label%3A%22JS%20API%20refinements%20(2025)%22

[kirillzyusko]

Hey @huntie

I believe that change will break react-native-keyboard-controller, because I rely on deep imports and I substitute NativeStatusBarManagerAndroid with own version that doesn't break edge-to-edge mode and removes keyboard listeners.

You can see here how it's done: https://github.com/kirillzyusko/react-native-keyboard-controller/blob/main/src/monkey-patch.android.ts (obviously the solution is a dirty workaround, but it was working for years 🙈)

I'll be happy to discuss a better solution/alternative for that or at least add temporarily NativeStatusBarManagerAndroid to official imports (but I don't think you want to do it?)

[huntie]

Noted, thanks. Yeah this is definitely a hack 😅

• Yup, promoting NativeStatusBarManagerAndroid directly to the public API isn't what we want.
• That's not to say we couldn't introduce an escape hatch, or a better API.

Give us some time as these requests stack up, and we'll loop back with an alternative (though in this case, not guaranteed).

[mrousavy]

[Done] Expose NativeComponentRegistry (facebook/react-native#52999)

Oh, sh*t. I just saw this - unfortunately I need a deep-import in Nitro.

I use NativeComponentRegistry (the default export from react-native/Libraries/NativeComponent/NativeComponentRegistry) to find a native view I registered using Nitro View components (custom ShadowNode stuff and all that).

I can't use codegenNativeComponent because I am not using codegen - the view code is generated using Nitrogen.

Is there any chance we can promote this to a public export?

[huntie]

@mrousavy Best to get some alignment first. I'm not particularly sure on this API decision. cc @cortinico @NickGerleman

[mrousavy]

Yea I think this is the only way to register a non-codegen'd component. And since the C++ APIs for creating ShadowNodes are public, it doesn't really make sense to make the API required to use said C++ component private.

See getHostComponent.ts.

[cortinico]

We'll have to discuss about this one. @mrousavy Having the PR out will facilitate the discussion IMHO 👍

Yea I think this is the only way to register a non-codegen'd component. And since the C++ APIs for creating ShadowNodes are public, it doesn't really make sense to make the API required to use said C++ component private.

Just note that sadly everything in C++ is practically public at this stage. This shouldn't be an argument to get more things exposed on the other layers though, as we might want to go the other way around (restricting the C++ visibility).

[mrousavy]

Wu created a PR for this here: facebook/react-native#52999

[cipolleschi]

My take here is that if it is impossible to create a Native Component without codegen (which is optional) with the API React Native provides because of this, then the NativeComponentRegistry must be public.
@cortinico @huntie

[mfkrause]

Just saw this through the 0.80 release.

Please consider exporting NativeText from react-native/Libraries/Text/TextNativeComponent and the default export from react-native/Libraries/Components/View/ViewNativeComponent. We use these in react-native-boost to replace Text and View components within apps, wherever possible, since they're more performant than the JS wrappers (especially Text). There's also a couple other libraries in the ecosystem that rely on them (Unistyles I think, for example).

[huntie]

Tentatively, sounds like libraries may need an interface to each Native* version of a component.

Thanks for the feedback, we're tracking these requests and will review what design might make sense down the line. cc @cortinico

[Pnlvfx]

Sorry I dunno if this is the right place to say that, I tried the new strict api on my react native project and I'm getting 94 parsing errors, I had to disabled it for now.

Let me know if you need any more info

See parsing errors

node_modules/react-native/Libraries/ReactPrivate/ReactNativePrivateInterface.js:128:34 - error TS1005: ';' expected.

128   get getNodeFromPublicInstance(): getNodeFromPublicInstance {
                                     ~

node_modules/react-native/Libraries/ReactPrivate/ReactNativePrivateInterface.js:128:36 - error TS1435: Unknown keyword or identifier. Did you mean 'get NodeFromPublicInstance'?

128   get getNodeFromPublicInstance(): getNodeFromPublicInstance {
                                       ~~~~~~~~~~~~~~~~~~~~~~~~~

node_modules/react-native/Libraries/ReactPrivate/ReactNativePrivateInterface.js:131:4 - error TS1128: Declaration or statement expected.

131   },
       ~

node_modules/react-native/Libraries/ReactPrivate/ReactNativePrivateInterface.js:132:3 - error TS1434: Unexpected keyword or identifier.

132   get getInternalInstanceHandleFromPublicInstance(): getInternalInstanceHandleFromPublicInstance {
      ~~~

node_modules/react-native/Libraries/ReactPrivate/ReactNativePrivateInterface.js:132:52 - error TS1005: ';' expected.

132   get getInternalInstanceHandleFromPublicInstance(): getInternalInstanceHandleFromPublicInstance {
                                                       ~

node_modules/react-native/Libraries/ReactPrivate/ReactNativePrivateInterface.js:132:54 - error TS1435: Unknown keyword or identifier. Did you mean 'get InternalInstanceHandleFromPublicInstance'?

132   get getInternalInstanceHandleFromPublicInstance(): getInternalInstanceHandleFromPublicInstance {
                                                         ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

node_modules/react-native/Libraries/ReactPrivate/ReactNativePrivateInterface.js:135:4 - error TS1128: Declaration or statement expected.

135   },
       ~

node_modules/react-native/Libraries/ReactPrivate/ReactNativePrivateInterface.js:136:1 - error TS1128: Declaration or statement expected.

136 };
    ~

Found 94 errors in the same file, starting at: node_modules/react-native/Libraries/ReactPrivate/ReactNativePrivateInterface.js:11.

I've some custom tsconfig but even after disabling them the result is the same.

[huntie]

@Pnlvfx This is expected — opting into the new API can be a breaking change. Please see our user guide for more information on tackling these breaking changes.

[Pnlvfx]

@Pnlvfx This is expected — opting into the new API can be a breaking change. Please see our user guide for more information on tackling these breaking changes.

Yes, I've read both blog posts. i did what the blog post say on the opt in section. the thing is that the errors are all coming from inside the node module, this are not error from my code.

more specifically they are all into this file:

node_modules/react-native/Libraries/ReactPrivate/ReactNativePrivateInterface.js

Should I add node modules on the exclude array on the tsconfig? I didn't see any mention about doing it

[j-piasecki]

@Pnlvfx Is there any chance you could prepare a reproduction for this? At first glance, it looks like TypeScript started picking up the Flow source code when you enabled the Strict API, but it didn't without it.

[Pnlvfx]

No, I'm sorry, I'm working on a mac with 120gb of memory and I don't even have space for the project I'm working on, I'm sorry. However I can provide my tsconfig in case you want to give them a shot and see if they break something, however as I said, I tried with the default and it still give me the same error.

N.B: I removed jest from the types array as written on the comment " removing jest from the default react-native tsconfig" because i'm not using jest and so I had to remove it from there, of course I've also removed all the test related packages including react-test-render. I don't think I changed anything else that could have affected typescript configs.

tsconfig.json

{
  "extends": "@react-native/typescript-config",
  "compilerOptions": {
    "types": ["react-native"], // removing jest from the default react-native tsconfig
    "noImplicitAny": true /* Enable error reporting for expressions and declarations with an implied 'any' type. */,
    "strictNullChecks": true /* When type checking, take into account 'null' and 'undefined'. */,
    "strictFunctionTypes": true /* When assigning functions, check to ensure parameters and the return values are subtype-compatible. */,
    "strictBindCallApply": true /* Check that the arguments for 'bind', 'call', and 'apply' methods match the original function. */,
    "strictPropertyInitialization": true /* Check for class properties that are declared but not set in the constructor. */,
    "noImplicitThis": true /* Enable error reporting when 'this' is given the type 'any'. */,
    "useUnknownInCatchVariables": true /* Default catch clause variables as 'unknown' instead of 'any'. */,
    "alwaysStrict": true /* Ensure 'use strict' is always emitted. */,
    "noUnusedLocals": true /* Enable error reporting when local variables aren't read. */,
    "noUnusedParameters": true /* Raise an error when a function parameter isn't read. */,
    "noImplicitReturns": true /* Enable error reporting for codepaths that do not explicitly return in a function. */,
    "noFallthroughCasesInSwitch": true /* Enable error reporting for fallthrough cases in switch statements. */,
    "noUncheckedIndexedAccess": true /* Add 'undefined' to a type when accessed using an index. */,
    "noImplicitOverride": true /* Ensure overriding members in derived classes are marked with an override modifier. */,
    "noPropertyAccessFromIndexSignature": true /* Enforces using indexed accessors for keys declared using an indexed type. */,
    "verbatimModuleSyntax": true,
    "removeComments": true,
    // "customConditions": ["react-native-strict-api"],
    "paths": {
    }
  }
}

[AlekseyP18]

same problem

[alexbrazier]

react-native-network-logger uses XHRInterceptor to intercept and display network requests the app makes. This is useful in dev and even prod builds (behind a flag) for devs and QAs to debug issues with an app after it's been built. Currently this is imported from react-native/src/private/devsupport/devmenu/elementinspector/XHRInterceptor. This is obviously an internal api that shouldn't be used by accident, so probably shouldn't be exposed at the root level, but if this was blocked and not exposed elsewhere then this library would stop working.

[huntie]

Definitely a private API.

• We're on track to ship first party Network debugging in React Native DevTools, in an upcoming release and before deep imports removal.
• Along with this, there will be somewhat of a replacement API from the JS side, via performance.getEntries().

[joshuayoes]

This is also used by Reactoton, Radon IDE, and this library.

https://github.com/search?q=react-native%2Fsrc%2Fprivate%2Fdevsupport%2Fdevmenu%2Felementinspector%2FXHRInterceptor&type=code

This is definitely a private API, but I feel maintaining some backwards compatibility for a while for this is important. I've been using React Native DevTools for a while and I really like it, but there are thousands of React Native developers using these tools that have filled this need for several years and have certain development habits built around using these tools.

[miquelbeltran]

The API XHRInterceptor is used as well by https://github.com/MindscapeHQ/raygun4reactnative for its Realtime User Monitoring network tracking.

[edoko]

Are there any additional measures to resolve this issue?
Has it been decided that the private API will not be used?

[jamonholmgren]

Just dropping this here -- Callstack has a Network Activity Plugin package they use in Rozenite. It looks like we could piggyback Reactotron on that, or use a similar approach. (Thanks to Callstack for building this!)

https://github.com/callstackincubator/rozenite/tree/main/packages/network-activity-plugin

[Titozzz]

[Done] Expose unstable_TextAncestorContext (facebook/react-native#52368)

Internally we import TextAncestorContext from import TextAncestor from 'react-native/Libraries/Text/TextAncestor';

It allows us to detect if we are rendering something inside a Text (we want to block it)

const useWarnHook =
  getNodeEnv() === 'development'
    ? () => {
        const isTextAncestor: boolean = useContext(TextAncestor);

        if (isTextAncestor) {
          printWarning('[ComponentName] should not be used inside a Text component');
        }
      }
    : undefined;

[huntie]

Are you able to replace this with findNodeHandle (docs)?

[tomekzaw]

findNodeHandle is not compatible with React.StrictMode I believe, that's why we had to migrate off from findNodeHandle in Reanimated and Gesture Handler

[huntie]

Alright, raising internally 👍🏻

[huntie]

Opened facebook/react-native#52368.

[vonovak]

Hello,
I just wanted to flag that while most RN deep imports were never advertised as correct, there is an exception which is the codegen: codegen stuff was always documented with deep imports and hence is widely used:

example GH search

migrating these to import from react-native will take a while (some libs will never migrate) and will remove support for pre-RN 0.80 versions in those libraries. Maybe these imports should stay available.

The new imports are done like this. This could be valuable to mention in the FAQ for library maintainers here.

[huntie]

We'll pay attention to this (high usage count + indeed previous status quo of documented subpaths). It should be functionally trivial to migrate libraries, but appreciate there could be a long tail.

A solution we could pursue is preserving + allowing these Codegen subpaths in our package (via package.json#exports), but continue to leave them out of our TypeScript API (type errors in each library, not surfacing to consuming apps).

[deusflow]

Thanks for the clarification! I wasn’t aware that deep imports were so widely used in the ecosystem. Looking forward to seeing what alternatives will be officially supported.

[troZee]

Does it mean the following mock will stop working in RN 0.82?

jest.mock('react-native/Libraries/Utilities/BackHandler', () => {
  const _backPressSubscriptions = new Set();
  const exitApp = jest.fn();
  return {
    __esModule: true,
    default: {
      getSubscriptions: function (): number {
        return _backPressSubscriptions.size;
      },
      exitApp,
      addEventListener: function (_eventName: string, handler: () => boolean) {
        _backPressSubscriptions.add(handler);
        return {
          remove: () => {
            _backPressSubscriptions.delete(handler);
          },
        };
      },

      mockPressBack: function () {
        let invokeDefault = true;
        const subscriptions = [..._backPressSubscriptions].reverse();
        for (let i = 0; i < subscriptions.length; ++i) {
          // @ts-expect-error it is just a mock
          if (subscriptions[i]()) {
            invokeDefault = false;
            break;
          }
        }

        if (invokeDefault) {
          exitApp();
        }
      },
    },
  };
});

hence, I should convert that into this:

jest.mock('react-native', () => {
  const _backPressSubscriptions = new Set();
  const exitApp = jest.fn();
  return {
    ...jest.requireActual("react-native"),
    BackHandler: {
      __esModule: true,
      default: {
        getSubscriptions: function (): number {
          return _backPressSubscriptions.size;
        },
        exitApp,
        addEventListener: function (
          _eventName: string,
          handler: () => boolean,
        ) {
          _backPressSubscriptions.add(handler);
          return {
            remove: () => {
              _backPressSubscriptions.delete(handler);
            },
          };
        },

        mockPressBack: function () {
          let invokeDefault = true;
          const subscriptions = [..._backPressSubscriptions].reverse();
          for (let i = 0; i < subscriptions.length; ++i) {
            // @ts-expect-error it is just a mock
            if (subscriptions[i]()) {
              invokeDefault = false;
              break;
            }
          }

          if (invokeDefault) {
            exitApp();
          }
        },
      },
    },
  };
});

Could you confirm that?

[huntie]

Tentatively yes — this aligns with any consumer of the react-native package not being able to reference internals, and we've migrated some of our own tests at Meta this way already.

As this is wide reaching, we may pursue a workaround for Jest and/or provide a migration guide when ready.

[jerone]

Am using the same mock for BackHandler in a similar fashion:

jest.mock<typeof import("react-native")>("react-native", () => {
  const originalModule =
    jest.requireActual<typeof import("react-native")>("react-native");

  const mockBackHandler = jest.requireActual<
    typeof import("react-native/Libraries/Utilities/BackHandler")
  >("react-native/Libraries/Utilities/__mocks__/BackHandler.js");

  // Mock `BackHandler` to use the mocked version that allows to simulate back button presses.
  Object.defineProperty(originalModule, "BackHandler", {
    get: () => mockBackHandler,
  });

  return originalModule;
});

I might as well copy-paste the mocked source, but hoping for an official solution...

[shirakaba]

My comment here flags some more Jest mocking (of the Platform API) that will stop working if deep imports are removed: #893 (comment)

[tido64]

[Done] Expose ReactNativeVersion (facebook/react-native#52784)

Is there a replacement for react-native/Libraries/Core/ReactNativeVersion? We use it in RNTA to display the current version. We copied this pattern from NewAppScreen.js which is also still using it.

(NOBRIDGE) WARN  Deep imports from the 'react-native' package are deprecated ('react-native/Libraries/Core/ReactNativeVersion'). Source: /~/example/App.tsx 14:0

[huntie]

Yeah needs to be promoted, and good to learn of another call site. I'll export a PR soon (as a mini RFC).

• Confusingly, we also have Platform.constants.reactNativeVersion, which is already public. However, this is not equivalent to ReactNativeVersion.js, as it's read from the native side and these values are actually compared at runtime in case of incompatibility.

[huntie]

facebook/react-native#52784

[graszka22]

In our project we're using Blob and BlobManager from react-native/Libraries/Blob/Blob.js and react-native/Libraries/Blob/BlobManager.js for encrypting binary files obtained by fetching them with fetch:

const response = await fetch(url);
const blob = await response.blob();
// do stuff with blob and encrypt it

Will it be available in future react-native versions or will be there a replacement for it?

[reichhartd]

expo-blob provides a web standards-compliant Blob implementation for React Native.

[cipolleschi]

@graszka22 are you sure you need them for those purposes? I can't find anything related to encrypting binaries in the Blob.js and BlobManage.js files.

As @reichhartd mentioned, expo-blob provides an implementation. If you can't use expo, there is also react-native-blob-utils that you can use

[shirakaba]

Please expose parseErrorStack() and symbolicateStackTrace(), as there's really no alternative to them. Currently they're only available as deep imports, e.g.:

import parseErrorStack from "react-native/Libraries/Core/Devtools/parseErrorStack";

parseErrorStack() is necessary for doing things like printing out error.cause the same way Node.js does.

I notice they're not currently in the provisional public API.

Currently both React Navigation and Sentry are manually parsing the error stack, which seems fragile (especially with Static Hermes on the horizon), and an unreasonable maintenance burden to have to do in userland.

I also want to implement proper stack traces for my userland util.inspect() polyfill that brings error.cause logging to React Native.

[cortinico]

cc @vzaidman @huntie

[shirakaba]

I am currently relying on a deep import of react-native/Libraries/Utilities/Platform in order to mock Platform fully in Jest.

The Platform API is incompletely mocked in both React Native and Expo's Jest presets (react-native/jest-preset.js and jest-expo/jest-preset.js, respectively). Specifically, the Version field is left undefined. For lack of any documented way to mock it otherwise, the only solution I was able to get working relies on a deep import:

const ReactNative = require("react-native");
// This approach only works with a deep import, not a shallow import.
const Platform = require("react-native/Libraries/Utilities/Platform");

/** @type {"ios" | "android"} */
const OS = "ios";

/** @type {import("react-native").Platform} */
const PlatformCommon = {
  OS,
  constants: {
    reactNativeVersion: {
      major: 1000,
      minor: 0,
      patch: 0,
      prerelease: undefined,
    },
  },
  __constants: null,
  isPad: false,
  isTV: false,
  isVision: false,
  isTesting: undefined,
  isDisableAnimations: undefined,
  isMacCatalyst: false,
  select: function select(spec) {
    return OS in spec
      ? spec[OS]
      : "native" in spec
        ? spec.native
        : spec.default;
  },
};

// TODO: find a way to swap between these based on test
const IosPlatform = { ...PlatformCommon, Version: "17.5" };
const AndroidPlatform = { ...PlatformCommon, Version: 33 };
const ResolvedPlatform = OS === "ios" ? IosPlatform : AndroidPlatform;

Object.assign(Platform, ResolvedPlatform);

Object.defineProperties(ReactNative, {
  Platform: {
    get: () => ResolvedPlatform,
  },
});

To be clear, I'm not proposing to expose the Platform deep import, but saying that improving the Jest presets (and docs for mocking React Native in general) should be a prerequisite to removing deep imports. Because if deep imports were to be removed today, it would break a lot of userland Jest tests, with no viable workarounds.

[jerone]

@shirakaba I don't have a use-case for the Version inside Platform, but I did need select and got it working without needing deep-imports. Maybe you can find some inspiration...

/**
 * Mocks the `react-native` package.
 * It mocks the `Platform.select` method to return the value for the current platform.
 */
jest.mock<typeof import("react-native")>("react-native", () => {
  const originalModule =
    jest.requireActual<typeof import("react-native")>("react-native");

  // Mock the `Platform.select` method to return the value for the current platform.
  jest
    .spyOn(originalModule.Platform, "select")
    .mockImplementation((specifics: PlatformSelect<unknown>): unknown =>
      originalModule.Platform.OS in specifics
        ? specifics[originalModule.Platform.OS]
        : "native" in specifics
          ? specifics.native
          : specifics.default,
    );

  return originalModule;
});

[huextrat]

CompositeAnimation is no longer exposed, before it was accessible Animated.CompositeAnimation

So if we have a parallel animation which has “CompositeAnimation” as its return type, it is not possible to correctly type my props

const bounceAnimation = Animated.parallel([
    Animated.sequence([
      Animated.timing(bounceAnim, {
        toValue: 1.04,
        duration: 100,
        useNativeDriver: true,
      }),
      Animated.timing(bounceAnim, {
        toValue: 1,
        duration: 100,
        useNativeDriver: true,
      }),
    ]),
  ]);

bounceAnimation: CompositeAnimation but there is no way to import the type

[huntie]

facebook/react-native#53538

[huextrat]

ViewToken is no longer exposed, this one is useful for inViewableItemsChanged on FlatList

const onViewableItemsChanged = React.useRef(
    ({ changed }: { changed: Array<ViewToken> }) => {
      console.log("changed", changed);
    },
  );

<FlatList
    ref={flatListRef}
    onViewableItemsChanged={onViewableItemsChanged.current}
    ...

There doesn't seem to be any alternative to typing this correctly.

[huntie]

facebook/react-native#53539

[jbroma]

Re.Pack Development APIs

Context

Re.Pack's HMR client (WebpackHMRClient) reimplements React Native's HMRClient and uses the following APIs:

1. NativeRedBox & NativeExceptionsManager

Module Paths:

• react-native/Libraries/NativeModules/specs/NativeRedBox
• react-native/Libraries/Core/NativeExceptionsManager

Purpose:
Dismissing error overlays during HMR updates.

Implementation:

if (__PLATFORM__ === 'ios') {
  const NativeRedBox =
    require('react-native/Libraries/NativeModules/specs/NativeRedBox').default;
  NativeRedBox?.dismiss?.();
} else {
  const NativeExceptionsManager =
    require('react-native/Libraries/Core/NativeExceptionsManager').default;
  NativeExceptionsManager?.dismissRedbox();
}

Source: WebpackHMRClient.ts

---

2. DevLoadingView

Module Paths:

• react-native/Libraries/Utilities/DevLoadingView

Purpose:
Displaying and hiding loading HMR refresh/reload messages.

Implementation:

const LoadingView = require('react-native/Libraries/Utilities/DevLoadingView');
LoadingView.showMessage(text, type);

Source: WebpackHMRClient.ts