[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?

[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": {
}
}
}

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

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