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

[huntie]

Introduction

See the RFC | See the 0.80 release post (incoming)

🚨 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.

[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).

[getsettalk]

@kirillzyusko is right , that deprecation of deep imports will break , before deprecate that must be sure to implement edge to edge and keyboard related fixes in react native core.

[mrousavy]

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?

[mrousavy]

I think without exposing NativeComponentRegistry no one can build handwritten Views / ShadowNodes. Which is something we should still support no?

[mrousavy]

@huntie do you want me to create a PR for that?

[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).

[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

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.

{
"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.

[Titozzz]

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.

[tido64]

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