Summary:
Pull Request resolved: https://github.com/react/react-native/pull/58063
Codegen's `EventEmitter<T>` support for TurboModules diverged between platforms
in two ways:
- The explicit number types `Double`, `Float` and `Int32` worked as emitter
payloads on Android and C++, but iOS rejected them at codegen time (plain
`number` worked). iOS now maps all of them to `NSNumber *_Nonnull`, matching
how plain `number` is already emitted.
- `ArrayBuffer` was rejected on Android and iOS, but the C++ generator silently
accepted it and produced a `jsi::ArrayBuffer` emitter. `ArrayBuffer` is not
emittable on any platform — Android emitters always carry a `folly::dynamic`
payload, which cannot hold raw bytes — and the schema type
`NativeModuleEventEmitterBaseTypeAnnotation` already excluded it. It is now
rejected everywhere.
`ArrayBuffer` payloads are rejected in the shared parser, so Flow and TypeScript
specs produce the same error, and the three generators keep an equivalent guard
so schemas that are constructed without going through the parser fail the same
way. `ArrayBuffer` remains supported as a method argument and as a synchronous
return value.
Changelog:
[iOS][Added] - Support `Double`, `Float` and `Int32` payloads for TurboModule `EventEmitter`s
[General][Breaking] - Reject `ArrayBuffer` as a TurboModule `EventEmitter` payload on all platforms
Reviewed By: GijsWeterings
Differential Revision: D116952150
fbshipit-source-id: e148a394c4916b3ebfbd3f559b190a5910b29de1
Summary:
`GeneratePropsJavaDelegate` emits the default value for an optional `DoubleTypeAnnotation` prop with an `f` (float) suffix, but the setter it calls takes a `double`:
```js
// GeneratePropsJavaDelegate.js
case 'DoubleTypeAnnotation':
if (prop.optional) {
return `value == null ? ${typeAnnotation.default}f : ((Double) value).doubleValue()`;
}
```
```js
// GeneratePropsJavaInterface.js — the setter this is passed to
case 'DoubleTypeAnnotation':
return 'double value';
```
The `f` literal is parsed as a `float`, then widened back to `double` at the call site, so the default silently arrives rounded to float precision. It compiles without a warning, which is why it has gone unnoticed.
This is visible in the repo's own snapshots today. Same fixture, same prop, two platforms:
| Generator | Output for `blurRadius3?: WithDefault<Double, 2.1>` |
| --- | --- |
| `GeneratePropsH` (C++) | `double blurRadius3{2.1};` |
| `GeneratePropsJavaDelegate` | `value == null ? 2.1f : ((Double) value).doubleValue()` |
So a component using the C++ renderer gets `2.1` and the same component on the Android delegate path gets `2.0999999046325684`.
Compiling the generated shape confirms it:
```java
static void setBlurRadius3(double value) { System.out.println(value); }
setBlurRadius3(value == null ? 2.1f : ...); // 2.0999999046325684
setBlurRadius3(value == null ? 123456789f : ...); // 1.23456792E8
```
The integer case is the clearest damage: any `Double` default above 2^24 is not representable as a `float`, so `123456789` arrives as `123456792`. Fractional defaults are wrong from the first value that is not a dyadic rational — `0.1`, `2.1`, and the fixture's own `0.001` all shift.
`FloatTypeAnnotation` on the line below is correct — it targets a `float` setter, so `f` is right there. Only the `Double` branch has the wrong suffix, which is consistent with it having been copied from the `Float` branch.
Changed to a `d` suffix, mirroring the existing `f` for float rather than dropping the suffix entirely, so the literal's type is stated rather than left to numeric promotion.
`DoubleTypeAnnotation` is never boxed by codegen (it is always a primitive `double`, defaulting to `Double.NaN` when non-optional), so there is no nullable-double path to consider.
## Changelog:
[ANDROID] [FIXED] - Fix `Double` prop defaults being rounded to float precision in generated `ViewManager` delegates
Pull Request resolved: https://github.com/react/react-native/pull/58070
Test Plan:
The generator is snapshot-tested, so the snapshot is the test. Updating it changes only the `Double` component and leaves the `Float` component untouched:
```diff
public class DoublePropNativeComponentManagerDelegate<T extends View, U extends ...
case "blurRadius2":
- mViewManager.setBlurRadius2(view, value == null ? 0.001f : ((Double) value).doubleValue());
+ mViewManager.setBlurRadius2(view, value == null ? 0.001d : ((Double) value).doubleValue());
case "blurRadius3":
- mViewManager.setBlurRadius3(view, value == null ? 2.1f : ((Double) value).doubleValue());
+ mViewManager.setBlurRadius3(view, value == null ? 2.1d : ((Double) value).doubleValue());
case "blurRadius4":
- mViewManager.setBlurRadius4(view, value == null ? 0f : ((Double) value).doubleValue());
+ mViewManager.setBlurRadius4(view, value == null ? 0d : ((Double) value).doubleValue());
case "blurRadius5":
- mViewManager.setBlurRadius5(view, value == null ? 1f : ((Double) value).doubleValue());
+ mViewManager.setBlurRadius5(view, value == null ? 1d : ((Double) value).doubleValue());
case "blurRadius6":
- mViewManager.setBlurRadius6(view, value == null ? 0f : ((Double) value).doubleValue());
+ mViewManager.setBlurRadius6(view, value == null ? 0d : ((Double) value).doubleValue());
```
```
$ yarn jest packages/react-native-codegen
Test Suites: 64 passed, 64 total
Tests: 3122 passed, 3122 total
Snapshots: 1277 passed, 1277 total
$ yarn flow-check
Found 0 errors
$ npx eslint packages/react-native-codegen/src/generators/components/GeneratePropsJavaDelegate.js
(no output)
```
`0d`, `1d` and `2.1d` are valid Java double literals; the proof snippet above compiles and runs under `java Proof.java`.
No committed generated sources carry the old output — `grep -rn "f : ((Double) value).doubleValue()" --include='*.java' --include='*.kt'` returns nothing outside the snapshot.
Reviewed By: christophpurrer
Differential Revision: D117082006
Pulled By: fabriziocucci
fbshipit-source-id: 7b61b16d36eea0dcedb9c2b047bf57d23c0132ca
Summary:
Fixes https://github.com/react/react-native/issues/57956.
A spec containing a type alias whose name matches the aliased `CodegenTypes` member hangs codegen forever:
```js
import type {CodegenTypes} from 'react-native';
type Double = CodegenTypes.Double;
```
`getResolvedTypeAnnotation` resolves `Double` to the alias's RHS (`CodegenTypes.Double`), but `getTypeAnnotationName` strips the namespace qualifier before the local-alias lookup — so the RHS resolves straight back to the same alias, forever. This hangs the Node process of anything driving the parser, most visibly ESLint via `react-native/eslint-plugin-specs`. Contrary to the issue's initial isolation, **both** the Flow and the TypeScript parsers hang (verified with a subprocess-timeout harness against both).
Two guards in each parser's resolution loop:
1. A qualified name (`CodegenTypes.Double` / `TSQualifiedName`) names a namespace member, never a local alias — stop local resolution there. Downstream translation already handles qualified names, so the alias now resolves to the correct primitive (`DoubleTypeAnnotation`).
2. Track resolved alias names, so genuinely cyclic aliases (`type A = B; type B = A;`) stop resolving and fail through the existing `UnsupportedGenericParserError` (`Unrecognized generic type 'A'`) instead of hanging.
## Changelog:
[GENERAL] [FIXED] - Codegen no longer hangs on type aliases that shadow CodegenTypes member names
Pull Request resolved: https://github.com/react/react-native/pull/57986
Test Plan:
- New `NAMESPACED_NATIVE_MODULE_WITH_LOCAL_TYPE_ALIASES` fixture in both the Flow and TypeScript module snapshot suites — before the fix these hang the test runner; after it they produce the correct schema (aliased `Double`/`Float` resolve to `DoubleTypeAnnotation`/`FloatTypeAnnotation`, snapshots included, cross-parser consistency suite passes).
- `jest packages/react-native-codegen/src/parsers`: 13 suites, 1965 tests, 186 snapshots — all passing.
- `jest packages/eslint-plugin-specs`: passing.
- Verified `type A = B; type B = A;` now throws `UnsupportedGenericParserError` instead of hanging.
Reviewed By: javache
Differential Revision: D116386584
Pulled By: christophpurrer
fbshipit-source-id: edbf04c8531d4dc35655318d6245918080ae55b7
Summary:
iOS TurboModules mapped a JS `ArrayBuffer` to `NSData` on arguments and `NSMutableData` on returns, so every crossing copied — and `NSMutableData` cannot alias foreign memory, so there was no way to express "these bytes live somewhere else".
This adds `RCTArrayBuffer` (`packages/react-native/React/Base/`) as the ObjC representation of an `ArrayBuffer`. It carries an `isOwningBytes` flag: an owning buffer can be stored and read from any thread, a non-owning one aliases bytes valid only for the synchronous call that produced it.
Codegen now emits `RCTArrayBuffer *` for `ArrayBufferTypeAnnotation` params (was `NSData *`) and returns (was `NSMutableData *`).
## Changelog:
[IOS] [BREAKING] - Add `RCTArrayBuffer`, the ObjC representation of a JS `ArrayBuffer` for TurboModules, with an explicit byte-ownership contract
Pull Request resolved: https://github.com/react/react-native/pull/57879
Test Plan:
- `RCTTurboModuleArrayBufferTests` — 9 tests over the sync in-place path, `isOwningBytes` on a sync argument, returning one's own argument, the void/Promise copy paths, nesting, and a zero-length round trip.
- `RCTTurboModuleTests.mm` adds `testNativeBackedArrayBufferIsAliasedAndKeepsBackingStoreAlive`.
- `RCTSampleTurboModule` doubles its argument in place and returns the same buffer, covering the path end to end.
- Codegen and C++ API snapshots regenerated.
Reviewed By: cipolleschi
Differential Revision: D115629409
Pulled By: christophpurrer
fbshipit-source-id: a7ee6eadf99fd5f9f82fd2a95b0d3ff1369f4ddf
Summary:
Android TurboModules mapped a JS `ArrayBuffer` to `java.nio.ByteBuffer`, copying every argument into a direct buffer — and `ByteBuffer` carries no ownership contract, so there was no way to express aliased or borrowed bytes for synchronous in-place access.
This adds `ArrayBuffer` (`packages/react-native/ReactAndroid/src/main/java/com/facebook/react/bridge/ArrayBuffer.kt`) as the Java representation of an `ArrayBuffer`. It carries an `isOwningBytes` flag: an owning buffer can be stored and returned to JS, a non-owning one aliases bytes valid only for the synchronous call that produced it.
Codegen now emits `ArrayBuffer` for `ArrayBufferTypeAnnotation` params (was `ByteBuffer`) and returns (was `ByteBuffer`).
## Changelog:
[ANDROID] [ADDED] - Add `ArrayBuffer`, the Java representation of a JS `ArrayBuffer` for TurboModules, with an explicit byte-ownership contract
Pull Request resolved: https://github.com/react/react-native/pull/57897
Test Plan:
- Codegen Java spec and JNI C++ snapshot tests updated for `ArrayBuffer` param/return signatures.
- `SampleTurboModule` doubles its sync argument in place and returns the same buffer, covering the zero-copy path end to end; `createNativeBuffer` allocates via `ArrayBuffer`.
- C++ API snapshots regenerated.
Reviewed By: javache
Differential Revision: D115755247
Pulled By: christophpurrer
fbshipit-source-id: de067789ad145b7202da721a02f838358c82f4d8
Summary:
Pull Request resolved: https://github.com/react/react-native/pull/57893
The codegen'd TurboModule `emitOn<Event>` methods invoked their `EventEmitterCallback` without checking it was set. That callback is installed by the generated `*SpecJSI` constructor, which runs when JS first looks the module up — so a native module that emits before that point invoked an empty `std::function` on iOS (`std::bad_function_call`) or a null field on Android (NPE). Native code commonly holds the module instance and pushes events well before any JS surface mounts, so call sites had to wrap every emit in a try/catch to stay crash-free.
Both generators now read the callback into a local and no-op when it is absent:
- ObjC++ (`serializeEventEmitter.js`): copies `_eventEmitterCallback`, calls it only if non-empty.
- Java (`GenerateModuleJavaSpec.js`): copies the `Nullable CxxCallbackImpl` field and null-checks it.
The local is for readability, not synchronization: the callback is installed once and never cleared, and Java reference reads are already atomic.
The `setEventEmitterCallback` lambdas had a separate lifetime bug: they captured `eventEmitterMap_` by reference and looked events up with `operator[]`. The Java/ObjC module owns the callback and can outlive the C++ `*SpecJSI` that installed it, so a stale callback dereferenced a dangling map; and `operator[]` silently default-inserted a null `shared_ptr` for an unknown event name, which the next line dereferenced. They now capture a copy of the map and use a checked `find` (`serializeModule.js`, `JavaTurboModule.cpp`). Every emitter is registered before the callback is installed, so the copy is complete.
Note the scope of the guarantee: it covers the ObjC++ and Java generators, which route through an `EventEmitterCallback`. A C++-only TurboModule (`<Module>CxxSpec`, from `GenerateModuleH.js`) has no callback to check — it emits through `eventEmitterMap_` entries its own constructor registers — so the "emit unconditionally" guidance is about the callback, not about emitting before construction finishes.
Changelog:
[General][Fixed] - TurboModule event emitters no longer throw when an event is emitted before the emitter callback is installed
Reviewed By: javache
Differential Revision: D115130767
fbshipit-source-id: 7d7b9a706b8983968e3e1207b22c66322f04a223
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/57752
## Rationale
Flow lib defs that declare global types (available anywhere, without an `import`) must be referenced in `.flowconfig` and can't be maintained incrementally. That's not too bad for very stable APIs and it's necessary for environment/runtime globals, but for 3P libraries it makes the lib defs much more difficult to maintain for little benefit (we have to import the runtime APIs anyway). Secondarily, it's a problem for generating TypeScript types, as TS doesn't declare any 3P library globally.
Babel is one of few cases where a library declares Flow globals - every one has an importable equivalent.
## This diff
Replaces usages of Babel global types across xplat/js with their `babel/types` equivalents
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D113574665
fbshipit-source-id: be668d968345a60e76a3515d19d8eaa002d53274
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/57596
The original implementation used `NSMutableData` for both directions of the
JSI<->ObjC ArrayBuffer conversion. That is the wrong contract on the argument
(JS -> ObjC/Native) side: an inbound buffer is owned by the caller, not the
native module, and `NSMutableData` must own a resizable backing store it can
`realloc`/`free`, so it cannot durably alias a foreign buffer.
This diff keeps `NSMutableData` for the ObjC/Native -> JS (return) path, but
switches the JS -> ObjC/Native (argument) path to the immutable `NSData`:
- Codegen: `getParamObjCType` now maps `ArrayBufferTypeAnnotation` params to
`NSData *` (return type stays `NSMutableData *`).
- Runtime: `convertJSIArrayBufferToNSMutableData` is renamed to
`convertJSIArrayBufferToNSData` and returns an immutable `NSData`. The bytes
are still eagerly copied, which keeps the result safe to retain, store, or
dispatch to another thread regardless of whether the source bytes were owned
by JS or by a native `MutableBuffer`.
- Updated the ObjC unit tests and the codegen `GenerateModuleHObjCpp` snapshot.
Changelog: [INTERNAL]
Reviewed By: javache
Differential Revision: D112582384
fbshipit-source-id: 8ed2dfb3f23e7f39677dfb1824c5530f378705bc
Summary:
Pull Request resolved: https://github.com/react/react-native/pull/57611
Directly follows D112733139 (Metro).
**Motivation**
- New Node builtins are *only* available under the prefix (e.g. `node:sqlite`), as this allows Node to introduce them without ecosystem-breaking changes, so this is the direction of travel and the only choice that'll allow consistency.
- Encouraging them and grouping them separately makes it easier to reason about a module's 3rd party dependencies.
Changelog: [Internal]
Reviewed By: robhogan
Differential Revision: D112803684
fbshipit-source-id: 40668d746a7151b3aa4800ff8af997902a18d198
Summary:
I'm doing CI/CD that includes React Native inside of https://tart.run/. Tart uses Apple Virtualization Framework, which in turn mounts VirtioFS volumes.
This feels like a common enough use case to contribute upstream, since I can envision many more people using Apple's virtualization features.
## Changelog:
[GENERAL] [FIXED] - react-native-codegen build.sh on AppleVirtIOFS volumes
Pull Request resolved: https://github.com/react/react-native/pull/57555
Test Plan: Run `packages/react-native-codegen/scripts/oss/build.sh` inside a virtual machine that uses Apple Virtualization Framework such as Tart
Reviewed By: cipolleschi
Differential Revision: D112091671
Pulled By: cortinico
fbshipit-source-id: 800e6ac54175aaf7a9dfb4b99950cbc6da86e085
Summary:
Adds ArrayBuffer support to ObjC TurboModules, following the C++ ArrayBuffer PR ([`226ef2e`](https://github.com/facebook/react-native/commit/226ef2e7c5d1928d5696dc23efc1b8950ba00e37)).
- Codegen support for `ArrayBufferTypeAnnotation` in ObjC module specs (`NSMutableData *` params/returns, new `ArrayBufferKind`)
- JSI↔ObjC conversion wraps native-backed buffers zero-copy via `-[NSMutableData initWithBytesNoCopy:length:deallocator:]`; the deallocator retains the backing store so the bytes stay valid even if the `NSMutableData` escapes the call or the source ArrayBuffer is garbage-collected
- JS-backed buffers are copied, which is safe on both the synchronous and asynchronous paths
This PR is iOS-only; Android support follows in a separate PR.
## Changelog:
[IOS] [ADDED] - Add ArrayBuffer support to ObjC TurboModules
X-link: https://github.com/facebook/react-native/pull/56986
Reviewed By: javache
Differential Revision: D106846249
Pulled By: christophpurrer
fbshipit-source-id: 3393d5d6f31a1412f5d52328c90e51205aa6b153
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/57034
With D107165685, it should work this time.
Changelog: [Internal]
Reviewed By: gkz
Differential Revision: D107111468
fbshipit-source-id: 326b2911088d7c87c3564a578125eeaab9d0b8cc
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/56998
Reverts the recent Flow syntax codemods applied across `packages/`, `private/`, and `scripts/` in react-native-github. Specifically restores the previous form for:
- `+T` / `+Instance` style variance annotations on generic type parameters that had been converted to the newer `out T` / `in T` keyword form.
- `+field:` covariant object/interface properties that had been converted to the `readonly field:` modifier form.
- `+[K in keyof T]:` mapped-type covariance that had been converted to `readonly [K in keyof T]:`.
These are purely Flow type-annotation changes with no runtime behavior impact, restoring the form that the rest of the toolchain (in particular Fantom) already supports.
Changelog: [Internal]
Reviewed By: christophpurrer
Differential Revision: D106813102
fbshipit-source-id: 6bf915d530e130eba9c9d96a2b6c3dc8853594d1
Summary:
Adds `ArrayBuffer` support to C++ TurboModules. This includes:
- Codegen support for `ArrayBufferTypeAnnotation` in module specs
- `AsyncArrayBuffer` — a move-only bridging type for holding ArrayBuffer data off the JS thread
- `Bridging<AsyncArrayBuffer>::toJs` for resolving promises with native-backed or owned-bytes buffers
iOS and Android support will follow in separate PRs. The new codegen type is currently restricted to C++ TurboModules via `excludedPlatforms: ['iOS', 'android']`.
## Changelog:
[GENERAL] [ADDED] - Add `ArrayBuffer` support to C++ TurboModules
Pull Request resolved: https://github.com/facebook/react-native/pull/56729
Test Plan:
- JS parser/generators tests added.
- New bridging unit tests in `BridgingTest.cpp` cover `AsyncArrayBuffer` construction and JS bridging.
- `rn-tester`: `getArrayBuffer`, `processAsyncBuffer`, and `getAsyncBuffer` methods added to `NativeCxxModuleExample` in demo app.
```
[chpurrer@54913.od /data/sandcastle/boxes/fbsource (a00a9a84e7)]$ buck test //xplat/js/react-native-github/packages/react-native/ReactCommon/react/bridging:tests
↷ Skip: fbsource//xplat/js/react-native-github/packages/react-native/ReactCommon/react/bridging:tests - BridgingTest.asyncArrayBufferBorrowNativeBackedTest (0.0s)
Note: Google Test filter = BridgingTest.asyncArrayBufferBorrowNativeBackedTest
[==========] Running 1 test from 1 test suite.
[----------] Global test environment set-up.
[----------] 1 test from BridgingTest
[ RUN ] BridgingTest.asyncArrayBufferBorrowNativeBackedTest
xplat/js/react-native-github/packages/react-native/ReactCommon/react/bridging/tests/BridgingTest.cpp:865: Skipped
Runtime does not expose tryGetMutableBuffer; borrow always throws
[ SKIPPED ] BridgingTest.asyncArrayBufferBorrowNativeBackedTest (7 ms)
[----------] 1 test from BridgingTest (7 ms total)
[----------] Global test environment tear-down
[==========] 1 test from 1 test suite ran. (7 ms total)
[ PASSED ] 0 tests.
[ SKIPPED ] 1 test, listed below:
[ SKIPPED ] BridgingTest.asyncArrayBufferBorrowNativeBackedTest
Buck UI: https://www.internalfb.com/buck2/4a7fa180-4ce6-4dcf-b685-45d183bd4091
Test UI: https://www.internalfb.com/intern/testinfra/testrun/30680772470375729
Network: Up: 0B Down: 0B (reSessionID-9a7e839f-b20c-4d94-944f-8d1720e694f8)
Command: test.
Time elapsed: 3.0s
Buck UI: https://www.internalfb.com/buck2/4a7fa180-4ce6-4dcf-b685-45d183bd4091
Tests finished: Pass 31. Fail 0. Timeout 0. Fatal 0. Skip 1. Omit 0. Infra Failure 0. Build failure 0
[chpurrer@54913.od /data/sandcastle/boxes/fbsource (a00a9a84e7)]$
```
## RNTester-ios
```
buck install -r rntester-ios
```
https://pxl.cl/9TgTf
Reviewed By: javache
Differential Revision: D105629442
Pulled By: christophpurrer
fbshipit-source-id: 91f6e3d16f69ba792469e02d6e539794e70b7101
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/56489
C++ enums cannot have float values - they must be int or long. This removes the invalid FloatEnum example (with values 0.0, 0.1, 0.2) from the react-native-codegen test fixtures and the corresponding enumFloat parameter reference. All affected test snapshots have been regenerated.
Changelog: [Internal]
Reviewed By: shwanton
Differential Revision: D101433764
fbshipit-source-id: eff21d3fa9c48ab11dfb8ef861ac0b8122ff5602
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/56258
According to my understanding, the codegen already outputs the modern casting syntax. Only these fixtures are stuck on the old syntax. This diff fixes them all.
Changelog: [Internal]
Reviewed By: gkz
Differential Revision: D98537137
fbshipit-source-id: 0d4a19e8eeece771881ed793ec994da25297de50
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/56049
Reduce duplication and inconsistency across codegen generators by centralizing reserved primitive type mappings into a single `ReservedPrimitiveTypes.js` registry, making future type support and fixes a single-source change and lowering bug risk.
Additionally, standardize identifier capitalization via a shared `toSafeIdentifier` helper in `Utils.js` to prevent divergent string handling across C++/Java helpers.
Also removes dead TODO comments and obsolete commented-out code from `RNCodegen.js`, `GenerateModuleH.js`, and parser files.
Changelog: [Internal]
Reviewed By: alanleedev
Differential Revision: D95711348
fbshipit-source-id: 3f541f91f8dcc21e8e8b75cf2f0e402807d18f8a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/56050
Removes ~75 lines of duplicated `toObjCType` logic between `serializeConstantsStruct.js` and `serializeRegularStruct.js` by extracting it into a new shared module `serializeStructUtils.js`. The two implementations were identical except for array wrapper types (`std::vector` vs `facebook::react::LazyVector`) and type alias suffixes (`::Builder` vs none), which are now handled via a `structContext` parameter that distinguishes between `CONSTANTS` and `REGULAR` contexts.
Changelog: [internal]
Reviewed By: philIip
Differential Revision: D95908134
fbshipit-source-id: c511958c40bf62fd970036f40f6575d8150c32df
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/56051
When parsing custom struct types in RN TurboModule flow specs for C++ (cxxOnly) codegen, the `getObjectTypeAnnotations` function in `parsers-commons.js` silently dropped types wrapped in `$ReadOnly<{...}>` or `Readonly<{...}>`.
The root cause: `parser.nextNodeForTypeAlias(value)` returns the raw right-hand side of a type alias. For `export type Foo = Readonly<{...}>`, this returns a `GenericTypeAnnotation` node (the `Readonly<...>` wrapper), not an `ObjectTypeAnnotation`. The existing guard check (`parent.type !== 'ObjectTypeAnnotation'`) then rejects the type, causing it to be silently skipped from the alias map.
The fix unwraps `$ReadOnly`/`Readonly` `GenericTypeAnnotation` wrappers (Flow) and `Readonly` `TSTypeReference` wrappers (TypeScript) before performing the type check, then obtains properties directly from the unwrapped node.
Also updates `NativeCxxModuleExample.js` to use `Readonly<{...}>` on `ConstantsStruct` as a demonstration and build-time validation of the fix.
Changelog: [Internal]
Reviewed By: vzaidman
Differential Revision: D96044884
fbshipit-source-id: 811ecb878ce573a2250b9e8ac54345bac42c7e07
Summary:
This PR fixes simple typos found in error messages:
- **apple.js**: Fixed "boostrap" -> "bootstrap" in error messages (lines 67, 169)
- **CppHelpers.js**: Fixed "informations" -> "information" in error messages (lines 75, 87, 101)
Note: "information" is an uncountable noun in English and should not be pluralized.
Changelog:
[Internal] [Changed] -
Pull Request resolved: https://github.com/facebook/react-native/pull/55849
Test Plan: These are typo fixes in error message strings. No code behavior changes.
Reviewed By: cipolleschi
Differential Revision: D94905006
Pulled By: cortinico
fbshipit-source-id: a6a7185cf3aeb8739212a06115100ede097b0b4c
React Native Bot