Summary:
Pull Request resolved: https://github.com/react/react-native/pull/58536
The auto-fix map behind `react-native/no-deep-imports` had drifted from the exports declared in `index.js.flow`, so the rule offered fixes that do not type-check and missed fixes it could have offered.
It was missing 28 modules, among them EventEmitter, CoreEventTypes, PlatformTypes, RendererProxy, usePressability, AssetRegistry and the virtual collection components. It still listed `InteractionManager`, which has been removed from the public API and whose root getter now throws in development, and `Touchable`, which is a value-only runtime re-export absent from the published types — auto-fixing either one produces broken code. It also carried a malformed `./Libraries/Utilities/PlatformTypes` key and two type names, `NativeMethods` and `NativeMethodsMixin`, that the root module does not export. The map is now generated from `index.js.flow`, so it tracks the real surface.
Two groups of exports stay out of the map on purpose. The rule keeps reporting those deep imports; it simply does not offer a fix for them.
Renamed re-exports such as `NativeText as unstable_NativeText`, and namespace re-exports such as `export * as Systrace`, cannot be expressed by a fixer that only rewrites same-name specifiers.
Names published behind an `unstable_` or `experimental_` prefix are excluded as well. They are genuine public exports, but rewriting a deep import of `ViewNativeComponent` into `unstable_NativeView` quietly moves a call site onto an experimental API, and that is a choice the author should make rather than a lint fixer.
`InitializeCore` and `RootTagTypes` remain hand-written entries, since neither is derivable from `index.js.flow`: the first has no root export at all and is replaced wholesale by the `react-native/setup-env` entry point, and the second re-exports `RootTag`, which the root does export.
Changelog:
[General][Fixed] - Align the `react-native/no-deep-imports` auto-fix map with the package's public API
Reviewed By: javache
Differential Revision: D119678373
fbshipit-source-id: c31bdbc5d6dd78dde52bd619fb54ff552e0763c9
Summary:
Pull Request resolved: https://github.com/react/react-native/pull/58452
**Cleanup**: The `react-private-interface` entry point (D111231527) now provides the private contract between React and React Native that `Libraries/ReactPrivate/` (deprecated) forwarded to. We can now delete.
**Changes**
- Delete `Libraries/ReactPrivate/` — `ReactNativePrivateInterface.js`, `ReactNativePrivateInitializeCore.js`, and their `.flow`/`README` files.
- Update internal module references to point to source modules.
- Update xplat/js references to use new private entry point.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D114055938
fbshipit-source-id: 01f0e6961ddb78d8a39eefc1d749a3deafe01d5f
Summary:
Pull Request resolved: https://github.com/react/react-native/pull/58391
Regenerate API snapshots after the bump. `flow-api-translator` picks up the fix in https://github.com/facebook/flow/pull/9486, which stops treating `async` functions with no explicit return annotation as `void` — updating `DependencyGraph#end` and `MetroServer#end` to their correct `Promise<void>` return type in `packages/metro/API.md`.
Changelog: [Internal]
Changelog: **[Types]**: `DependencyGraph#end` and `MetroServer#end` are now correctly declared as returning `Promise<void>` rather than `void`
X-link: https://github.com/react/metro/pull/1909
Test Plan:
```
yarn typecheck
yarn lint
yarn build
yarn run verify-api-snapshots
```
All pass.
Reviewed By: mweststrate
Differential Revision: D119090467
Pulled By: javache
fbshipit-source-id: 21b65f90ed511e0cb035917eaf1b0ca399ece855
Summary:
Pull Request resolved: https://github.com/react/react-native/pull/57851
The flow-* packages have support for all latest syntax and is better maintained.
Changelog: [Internal]
Reviewed By: huntie
Differential Revision: D115064040
fbshipit-source-id: 7265eb722910a460c76d0dbde0603cf962fe4e4e
Summary:
Pull Request resolved: https://github.com/react/react-native/pull/57705
An implementation for the RFC in https://github.com/react-native-community/discussions-and-proposals/pull/1008
Rounds out the lazy `PlatformColor` fallback with tooling and a demo.
- The `react-native/platform-colors` ESLint rule now permits an optional trailing `{fallback: <literal>}` options object so `PlatformColor('token', {fallback: '#RRGGBB'})` is lint-clean, while still requiring every other argument to be a literal. The options object must have exactly one `fallback` property whose value is a literal, so it stays statically analyzable.
- A new "Lazy Fallback Colors" section in the RNTester `PlatformColor` example demonstrates valid tokens, misses with no fallback (transparent), and misses with hex / `rgb()` / `rgba()` / `#RRGGBBAA` fallbacks across `backgroundColor`, text `color`, and `borderColor`.
Changelog:
[Internal] - PlatformColor: ESLint support and RNTester example for the lazy raw-color fallback
Reviewed By: christophpurrer
Differential Revision: D113329138
fbshipit-source-id: 7d38a8d55b54615d1b131591e99d13e6299eb5cb
Summary:
Pull Request resolved: https://github.com/react/react-native/pull/57769
Eventually, we will replace the hermes ones with the `flow-{estree,eslint,parser,transform}` packages. This diff first installs the flow ones.
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D114226573
fbshipit-source-id: a693cdac57d2ce77c002a8ac455aceabaadbcf20
Summary:
Pull Request resolved: https://github.com/react/react-native/pull/57510
Extend `check-packages-test.js` to catch two more classes of manifest drift: published packages missing required fields, and packages under `private/` missing the `private` flag.
**Motivation**
Inspired by https://github.com/react-native-community/template/pull/241 — avoid a missing field blocking a future RN package publish.
**Other changes**
- To satisfy the new `files` requirement, add an explicit `files` allowlist to the four config packages that lacked one. As a side effect, this saves some `__tests__` files from being distributed.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D111471314
fbshipit-source-id: e13082d2282128936e22e3a7580b5e434c3b41b2
Summary:
Pull Request resolved: https://github.com/react/react-native/pull/57475
NOTE: Resubmission of D110890810.
Replace `'react-native/Libraries/Core/InitializeCore'` with an explicit `'react-native/setup-env'` secondary export.
This was previously a special-case path excluded from our ESLint warnings. It is now formalised.
**Changes**
- Add new `src/setup-env.js` entry point and `package.json` mapping.
- Replace references in `packages/metro-config/` and `packages/community-cli-plugin/`.
- Update `warn-on-deep-imports` ESLint rule.
Changelog:
[General][Added] - Add `'react-native/setup-env'` entry point. This replaces the previous side-effectful `'react-native/Libraries/Core/InitializeCore'`.
[General][Deprecated] - Deprecate `'react-native/Libraries/Core/InitializeCore'`. Use `'react-native/setup-env'` instead.
Reviewed By: rubennorte
Differential Revision: D111022546
fbshipit-source-id: c9081997468b55b02c8a89544c7cb2026d625ad3
Summary:
Pull Request resolved: https://github.com/react/react-native/pull/57461
Replace `'react-native/Libraries/Core/InitializeCore'` with an explicit `'react-native/setup-env'` secondary export.
This was previously a special-case path excluded from our ESLint warnings. It is now formalised.
**Changes**
- Add new `src/setup-env.js` entry point and `package.json` mapping.
- Replace references in `packages/metro-config/` and `packages/community-cli-plugin/`.
- Update `warn-on-deep-imports` ESLint rule.
Changelog:
[General][Added] - Add `'react-native/setup-env'` entry point. This replaces the previous side-effectful `'react-native/Libraries/Core/InitializeCore'`.
[General][Deprecated] - Deprecate `'react-native/Libraries/Core/InitializeCore'`. Use `'react-native/setup-env'` instead.
Reviewed By: rubennorte
Differential Revision: D110890810
fbshipit-source-id: 3afe25efa45548d593a1b09c436e36038350b4c5
Summary:
Pull Request resolved: https://github.com/react/react-native/pull/57369
**Problem**
The separate `react-native/assets-registry` package includes a longstanding ecosystem footgun.
`registry.js` holds asset state in a module-scoped variable, which makes the package a stateful singleton: exactly one instance must exist per JS runtime, or registration and lookup diverge.
We provide no guarantee that this singleton requirement holds:
- The install layout — how the package manager dedupes packages in `node_modules` — decides how many copies exist, and `react-native`'s exact-version pin means third-party ranges never dedupe against it.
Effects:
- **Consumers silently break**: `expo-asset` and `expo-image` can land on a second copy: assets register in one, resolve as `undefined` from the other. Expo neutralizes this with a shim in `expo/cli` that redirects every registry import to a single virtual module — bare React Native + Metro has no such protection.
- **This blocks 1.0**: The ecosystem can't move from exact-version lockstep to semver ranges until stateful packages like the asset registry are safe to duplicate. Today, relaxing the pin would turn a latent footgun into a common one.
**To solve this**, move towards (but not quite yet) deleting `react-native/assets-registry`, in favour of a replacement `AssetRegistry` API offered directly by `react-native`.
**Key changes**
NOTE: **Reviewer note**: Browsing file changes on GitHub may be more focused — https://github.com/react/react-native/pull/57369/changes
NOTE: Squash of https://github.com/react/react-native/pull/57233 (D108750302) and https://github.com/react/react-native/pull/57232 (D108750303)
`'react-native'`:
- Add new `AssetRegistry` API, along with the `PackagerAsset` and `AssetDestPathResolver` root type exports in `react-native`.
- Add a new `'react-native/asset-registry'` secondary entry point — intended for Metro's `transformer.assetRegistryPath` config contract.
`react-native/assets-registry`:
- Update to source from this relocated implementation — fixing the duplicate install layout bug (where apps/frameworks enforce a single copy of `react-native`).
**Impact**
- **✅ Fixed**: Imports from either `react-native` or `react-native/assets-registry` in RN 0.87+ will be durable to duplicate package installs — Expo can remove their virtual module shim.
- **✅ Fixed**: Deep import `'react-native/Libraries/Image/AssetRegistry'` dependency removed (migrated in `react-native/metro-config`).
Changelog:
- [General][Fixed] - **assets-registry**: `react-native/assets-registry` now shares state across duplicate installs, sourcing from a relocated implementation in the `react-native` package
- [General][Added] - Add `AssetRegistry` API (replaces `react-native/assets-registry/registry`)
- [General][Breaking] - `react-native/Libraries/Image/AssetRegistry` is removed. Please use the `AssetRegistry` API (apps/library code) and/or the `react-native/asset-registry` entrypoint (Metro/build configs).
Reviewed By: robhogan
Differential Revision: D109019622
fbshipit-source-id: 75599a94a9aba084a1266f2128c448379d1596cd
Summary:
Pull Request resolved: https://github.com/react/react-native/pull/57273
**Motivation**
A README is the first thing an npm visitor sees on each package; internal-repo boilerplate like the "Testing" sections and the "We're using yarn…" note doesn't belong on a published package page.
**Changes**
- Standardize every README: a `# react-native/<name>` heading, a user-facing description, and a blue version badge plus a green monthly-downloads badge.
- Keep the "internal dependency" prelude only on `community-cli-plugin`, `virtualized-lists`, and `js-polyfills`.
- Drop the monorepo-template "Testing" sections and yarn note.
- Rework `metro-config` around the Configuring Metro guide; add missing READMEs for `metro-babel-transformer` and `popup-menu-android`.
Changelog: [Internal]
Reviewed By: emily8rown
Differential Revision: D109017270
fbshipit-source-id: 6208294c4ad2e6235a6605ae54f22d730f0476e7
Summary:
Pull Request resolved: https://github.com/react/react-native/pull/57258
Reflecting the move to https://github.com/react/react-native , update references in first-party `package.json`s
The `repository.url` field in particular is load-bearing for Trusted Publish.
Changelog: [Internal]
___
Reviewed By: fabriziocucci
Differential Revision: D108986410
fbshipit-source-id: 78513ffefc32ddf417dc1479a4834ebc44240080
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/57047
**Motivation**
`NativeDialogManagerAndroid` is an internal native module used by `Alert` and `PermissionsAndroid` on Android, not an intended root React Native public API.
**Notes**
- `NativeDialogManagerAndroid` wasn't defined on our manual public TypeScript types — so was never discoverable via TypeScript auto-import.
- Appears unused by open source consumers with public code on GitHub ([search](https://github.com/search?type=code&q=NativeDialogManagerAndroid++NOT+is%3Aarchived+NOT+is%3Afork+language%3ATypeScript&l=TypeScript⁄)).
Changelog:
[General][Breaking] - The `NativeDialogManagerAndroid` export is removed.
Reviewed By: cortinico
Differential Revision: D107250968
fbshipit-source-id: 6d44fe7a08e14f07ee6eb9274d2620760961b598
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/57026
`InteractionManager` has been marked as deprecated and has emitted a runtime warning on first access for several releases. Remove it from the public API.
Accessing `InteractionManager` from `react-native` now throws a `__DEV__` invariant with a migration message pointing at `requestIdleCallback`, mirroring the pattern already used for other previously-removed legacy modules.
The recommended migration is to refactor long tasks into smaller chunks and use `requestIdleCallback` / `cancelIdleCallback` instead of `runAfterInteractions` / `handle.cancel()`.
Changes:
- Remove the lazy getter from `index.js` and replace it with a `__DEV__` invariant stub.
- Remove the `Handle`, `PromiseTask`, `SimpleTask` type re-exports and the `InteractionManager` default re-export from `index.js.flow`.
- Delete `Libraries/Interaction/InteractionManager.js` and its `.d.ts`. The parent `Libraries/Interaction/` directory is kept — `PanResponder`, `TouchHistoryMath`, and `FrameRateLogger` continue to live there.
Changelog:
[General][Removed] - Remove deprecated `InteractionManager` (use `requestIdleCallback` instead)
Reviewed By: huntie
Differential Revision: D106640958
fbshipit-source-id: 01a15fa46b9c840473d96ae9d4ab8b4da4699352
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/56887
Drop support for Node.js 20. The minimum supported version is now `^22.13.0 || ^24.3.0 || >= 26.0.0`.
Node.js 20 reached end-of-life in April 2026 and is no longer actively maintained. This aligns React Native with the upcoming Metro requirement.
Changelog:
[General][Breaking] - Require Node.js >= 22.13.0
Reviewed By: christophpurrer, cortinico
Differential Revision: D105685641
fbshipit-source-id: f490e5a13e4289daba98c4d56dd8fdd341aef0db
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/55114
Our official [docs](https://reactnative.dev/docs/set-up-your-environment#node--watchman) require:
> Node 20.19.4 or newer
Currently, our `package.json#engines` fields express this as `"node": ">= 20.19.4"`
This is a bit imprecise because of Node's overlapping release lines - e.g. v24.0.0 is actually older than v20.19.4 (2025-07-15), and the whole v21 line was already EOL before v20.19.4.
The release *date* is relevant because Node.js frequently backports the most important updates - notably, `require(esm)` is already stable in Node 20.19 but is not unflagged in v22 until v22.12.
This makes the `package.json#engines` requirement truer to the documented requirement, dropping some old minors and EOL majors that prevent us using features included in v20.19.
Notably, `require(esm)` is stable and unflagged on all versions supported from this diff.
- v21 and v23 are EOL, so are dropped.
- v22.13 pre-dates 20.19.4 and is the first to have unflagged silent `require(esm)`
- v24.3.0 pre-dates 20.19.4 and is the first to unflag TS-stripping
- Support v25 and newer.
Changelog:
[General][Breaking] Drop support for EOL Node.js lines and old minors.
Reviewed By: cortinico, huntie
Differential Revision: D90467358
fbshipit-source-id: a5fdfb1b93a9d6cffe78eb6811ff7420ab906f44
Summary:
Implements: https://github.com/facebook/react-native/issues/42996
Add support for Flat config (eslint v9) to `eslint-config-react-native`. To achieve this, I created `packages/eslint-config-react-native/flat.js` to export flat config as well as maintain legacy config for backward compatibility. I recognize we have had [the PR for supporting Flat config](https://github.com/facebook/react-native/issues/42996) already, but it looks stale and doesn't seem likely to move forward. That's why I created this PR.
I also updated `eslint-plugin-react-native` and `eslint-plugin-specs` so that they comply with the current eslint plugin format.
## Changelog:
[GENERAL] [ADDED] - Add support for Flat Config (eslint v9)
Pull Request resolved: https://github.com/facebook/react-native/pull/54297
Test Plan:
1. Pull this branch into your local machine
2. `cd packages/eslint-config-react-native`
3. `yarn link`
4. Clone https://github.com/pipopotamasu/rn-eslint-config-test in your local machine
5. `cd path/to/rn-eslint-config-test`
6. `yarn install`
7. `yarn link "react-native/eslint-config"`
8. `yarn lint`
9. Confirm that eslint rules from `react-native/eslint-config` are applied
<img width="1470" height="628" alt="image" src="https://github.com/user-attachments/assets/955fd655-8a79-4dd4-9031-e505d218d63a" />
Reviewed By: vzaidman
Differential Revision: D85851077
Pulled By: huntie
fbshipit-source-id: 9c78ecc4f5c3b10175a89417628b599735f95215
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/54009
Packages haven't been bumped on main ahead of 0.83. This takes care of it.
Changelog:
[Internal] [Changed] -
Reviewed By: cipolleschi, huntie
Differential Revision: D83580515
fbshipit-source-id: 7471e77f74e3fb3b4ee6538a49369b5df1393098
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52706
This just prepares the repo for the next branch cut.
Changelog:
[Internal] [Changed] -
Reviewed By: cipolleschi
Differential Revision: D78558445
fbshipit-source-id: 2132d560dad447b3685874438387a519587f8554
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52678
From partner feedback, there's still appetite to support Node 20.x for the next <1y of life. Lower min version to `20.19.4` (Jul 2025) and widen test matrix in CI.
Changelog:
[General][Breaking] - Our new minimum Node version is Node.js 20 (Overrides #51840)
Reviewed By: cortinico
Differential Revision: D78494491
fbshipit-source-id: c8d9dc6250cb11f8a12ca7e761b65f4a8dae9265
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52359
This is needed ahead of the 81 branch cut.
Changelog:
[Internal] - Bump all packages to 0.81.0-main
Reviewed By: huntie
Differential Revision: D77602196
fbshipit-source-id: 1b52a7d1577783d72aba8d20f98032f29ffcc7df
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52365
Adds type imports autofix support and pass `fb_internal` paths in react native deep imports eslint rule. The rule fixes imports with all matched types with static API mapping to prevent splits.
Changelog:
[Internal]
Reviewed By: huntie
Differential Revision: D77445445
fbshipit-source-id: cd5b75b4b3b53792117b8297352dddc4d63dbf70
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51840
Bumps the minimum version of Node.js in React Native to the current active LTS release (22.x, upgraded from 18.x which is now out of support).
- CI configurations are reduced from `[22, 20, 18]` to `[24, 22]`.
{F1978909878}
See https://nodejs.org/en/about/previous-releases.
Changelog:
[General][Breaking] - Our new minimum Node version is Node.js 22
Reviewed By: yungsters, cortinico
Differential Revision: D76037015
fbshipit-source-id: b6e4b3ee279a9a93d716a13297420bba73f45250
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51778
Adds `noflow` to a bunch of ESLint and Babel files that are expected to be evaluated using Node.js without Babel. Additioanlly, these files tend to depend on ESLint and Babel type definitions that are not currently readily available.
In the future, these files could be migrated to use `flow strict-local` or `flow strict` using comment syntax for type annotations. But for now, adding `noflow` makes it explicit that these are known to not be typechecked.
Changelog:
[Internal]
Reviewed By: SamChou19815
Differential Revision: D75883642
fbshipit-source-id: 54236d123ca8773de42bce81189dfb5c0671563e