Summary:
Pull Request resolved: https://github.com/react/react-native/pull/58651
Generated view configs currently emit repeated property accesses from React Native entry-point requires and route commands through a renderer namespace. Consolidate imports by source and expose `dispatchCommand` directly from the unstable internals entry point, reducing generated Hermes bytecode while preserving existing stable root exports. Metro's inline-require transform would otherwise expand the consolidated unstable-internals binding back into repeated `require(...)` calls, so keep that dependency non-inlined while leaving other generated imports eligible for lazy loading. Make the unstable `HMRClient` export follow React Native's normal development/production selection so production consumers receive `HMRClientProdShim` instead of including HMR tooling.
Changelog:
[General][Fixed] - Reduce generated native component bundle overhead
Reviewed By: javache
Differential Revision: D121383217
fbshipit-source-id: 3b81db620bcff172d43d0493dd4ca22b30f305d6
Summary:
Pull Request resolved: https://github.com/react/react-native/pull/58603
Generate view configs and Codegen fixtures using supported React Native entry points or values derived from their exports. Generated view config modules can be emitted into arbitrary consumer package locations, so they cannot use a package-relative path back into React Native. Keep `ConditionallyIgnoredEventHandlers` centralized and expose it from the explicitly unstable compatibility entry point instead of duplicating its platform-specific semantics in generated output.
Changelog: [Internal]
Reviewed By: cipolleschi
Differential Revision: D120717571
fbshipit-source-id: 9f3ea06d393eb8702bbb3ef2767c2d7c5fde1315
Summary:
Pull Request resolved: https://github.com/react/react-native/pull/58558
Generate TurboModule interfaces using the public Bridging C++ entry point so generated consumers remain compatible with the strict API boundary.
Export the bridging module include root from its CMake target so source-built consumers can resolve <React/Bridging.h>.
Changelog:
[Internal]
Reviewed By: cortinico
Differential Revision: D120357994
fbshipit-source-id: 072d67197daf19acffbb66c110833a10a7094cfb
Summary:
Pull Request resolved: https://github.com/react/react-native/pull/58572
Migrate Codegen and compatibility fixtures from React Native deep imports to the public `react-native` entry point. Reference codegen-only types through the exported `CodegenTypes` namespace.
Changelog: [Internal]
Reviewed By: christophpurrer
Differential Revision: D120537584
fbshipit-source-id: f97ee85fb5f16d23a998d25c1544134ee08bc3cc
Summary:
Pull Request resolved: https://github.com/react/react-native/pull/58539
Update Fabric component codegen to consume the public View module through <React/View.h> for generated props, event emitters, shadow nodes, and dimension conversions. Refresh generated snapshots and checked-in popup-menu bindings, and add strict consumer compile coverage that does not use RN_BUILDING.
Make the View umbrella compatible with force-CXX platform configurations discovered by the broader generated-header coverage. On Android, gate the ViewPropsInterpolation rawProps workaround on both ANDROID and RN_SERIALIZABLE_STATE, since rawProps only exists when serializable state is enabled; this preserves existing Android behavior without enabling the runtime/ABI feature globally. For Android, macOS, and Windows platform types, rely on the Buck-selected HostPlatformViewProps and HostPlatformViewEventEmitter headers instead of compiler platform macros: the native implementations already expose NativeDrawable, HostPlatformViewEvents, KeyEvent, MouseEvent, and WindowsViewEvents, while force-CXX builds intentionally do not export those platform-only headers.
Changelog:
[Internal].
Reviewed By: cipolleschi
Differential Revision: D119490247
fbshipit-source-id: 7266baa57f5629e56134b65f2a6b591cb1e0b155
Summary:
Pull Request resolved: https://github.com/react/react-native/pull/58554
Generate component descriptor headers through the public <React/ComponentRegistry.h> umbrella instead of directly including ComponentDescriptorProviderRegistry.h. Refresh codegen snapshots and the checked-in popup-menu binding, and export the ComponentRegistry dependency needed by that public generated header.
Changelog:
[Internal].
Reviewed By: cipolleschi
Differential Revision: D120317127
fbshipit-source-id: fedea53bbe65e22ae53ed00a7fde787b2581bfab
Summary:
Pull Request resolved: https://github.com/react/react-native/pull/58486
Generate TurboModule interfaces using the public Bridging C++ entry point so generated consumers remain compatible with the strict API boundary.
Changelog:
[Internal]
Reviewed By: cipolleschi
Differential Revision: D119658518
fbshipit-source-id: 42b2c23c8a1c4264704a916b0c4e19660110a86d
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/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/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:
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/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/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
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/55676
Change `GenerateViewConfigJs.js` to emit `require('.../ReactNativeStyleAttributes').colorAttribute` for `ColorPrimitive` props instead of the inline `{process: require('.../processColor').default}`. This ensures generated ViewConfigs use the same gated attribute as handwritten ones.
Changelog: [Internal]
Reviewed By: lenaic
Differential Revision: D94052698
fbshipit-source-id: aa4821364062807b0ae862379d236a2f458c9c53
Summary:
I was upgrading bare react native project to expo sdk 54 and stumbled upon
```
"TurboModule system assumes returnType == void iff the method is synchronous."
```
error from `turbomodule/core/TurboModuleInteropUtils.kt`
I thought that `iff` with double `f` was a typo and wanted to submit a pr with fix - I learned that it means `if and only if` - decided to scan the repo for any other typos anywany - submitting the ones that I've found.
## Changelog:
[Internal]
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
[ANDROID|GENERAL|IOS|INTERNAL] [BREAKING|ADDED|CHANGED|DEPRECATED|REMOVED|FIXED|SECURITY] - Message
Pull Request resolved: https://github.com/facebook/react-native/pull/55651
Reviewed By: cipolleschi
Differential Revision: D93876470
Pulled By: cortinico
fbshipit-source-id: 43fc905bda14e77b27cdeda568bde1e2299d9d0f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/55484
This change adds content validation to ensure module names only contain safe identifier characters (alphanumeric and underscores, matching `^[a-zA-Z_][a-zA-Z0-9_]*$`). A new error class `IncorrectModuleRegistryCallArgumentValueParserError` provides a clear error message when an unsafe module name is detected.
Changelog: [Android][Fixed] - Validate module names in codegen
Reviewed By: CalixTang
Differential Revision: D92736956
fbshipit-source-id: 29b2c603bf97f9a2c30c8350d29b468d315765f0
Summary:
Changelog: [Internal] support flow 'unknown' syntax
Pull Request resolved: https://github.com/facebook/react-native/pull/54941
`buck build --flagfile fbcode//mode/opt fbcode//cathode/modules/react/lib/tests:app_delegate_test` crashed with
```javascript
Buck build failed for this target, and is likely caused by your changes.
Error message:
[New Failure] Target failed to build.
Action failed: fbsource//xplat/js/RKJSModules/Libraries/CathodeMessaging:FBReactNativeCathodeMessagingSpec-flow-types-ota-safety (cfg:opt-linux-x86_64-fbcode-platform010-clang19-no-san#3224936a2623a72b) (genrule)
Remote command returned non-zero exit code 1
Remote action, reproduce with: `frecli cas download-action 0c073e461a3ae239aa7e24c8a99b39543d365414405d1be1caa2196d7f55a18e:148`
Stdout: <empty>
Stderr:
UnsupportedGenericParserError: Module NativeCathodeMessagingModuleCxx: Unrecognized generic type 'unknown' in NativeModule spec.
at translateTypeAnnotation (/re_cwd/buck-out/v2/gen/fbsource/xplat/js/tools/flow-schema/__flow-schema__bin_build__/0a63598ffadb2c1e/out/flow-schema__bin_build.zip/node_modules/react-native/codegen/src/parsers/flow/modules/index.js:154:23)
at /re_cwd/buck-out/v2/gen/fbsource/xplat/js/tools/flow-schema/__flow-schema__bin_build__/0a63598ffadb2c1e/out/flow-schema__bin_build.zip/node_modules/react-native/codegen/src/parsers/parsers-commons.js:343:7
at guard (/re_cwd/buck-out/v2/gen/fbsource/xplat/js/tools/flow-schema/__flow-schema__bin_build__/0a63598ffadb2c1e/out/flow-schema__bin_build.zip/node_modules/react-native/codegen/src/parsers/utils.js:50:14)
at translateFunctionTypeAnnotation (/re_cwd/buck-out/v2/gen/fbsource/xplat/js/tools/flow-schema/__flow-schema__bin_build__/0a63598ffadb2c1e/out/flow-schema__bin_build.zip/node_modules/react-native/codegen/src/parsers/parsers-commons.js:334:25)
at emitFunction (/re_cwd/buck-out/v2/gen/fbsource/xplat/js/tools/flow-schema/__flow-schema__bin_build__/0a63598ffadb2c1e/out/flow-schema__bin_build.zip/node_modules/react-native/codegen/src/parsers/parsers-primitives.js:149:3)
at translateTypeAnnotation (/re_cwd/buck-out/v2/gen/fbsource/xplat/js/tools/flow-schema/__flow-schema__bin_build__/0a63598ffadb2c1e/out/flow-schema__bin_build.zip/node_modules/react-native/codegen/src/parsers/flow/modules/index.js:236:16)
at /re_cwd/buck-out/v2/gen/fbsource/xplat/js/tools/flow-schema/__flow-schema__bin_build__/0a63598ffadb2c1e/out/flow-schema__bin_build.zip/node_modules/react-native/codegen/src/parsers/parsers-commons.js:343:7
at guard (/re_cwd/buck-out/v2/gen/fbsource/xplat/js/tools/flow-schema/__flow-schema__bin_build__/0a63598ffadb2c1e/out/flow-schema__bin_build.zip/node_modules/react-native/codegen/src/parsers/utils.js:50:14)
at translateFunctionTypeAnnotation (/re_cwd/buck-out/v2/gen/fbsource/xplat/js/tools/flow-schema/__flow-schema__bin_build__/0a63598ffadb2c1e/out/flow-schema__bin_build.zip/node_modules/react-native/codegen/src/parsers/parsers-commons.js:334:25)
at buildPropertySchema (/re_cwd/buck-out/v2/gen/fbsource/xplat/js/tools/flow-schema/__flow-schema__bin_build__/0a63598ffadb2c1e/out/flow-schema__bin_build.zip/node_modules/react-native/codegen/src/parsers/parsers-commons.js:461:5)
at /re_cwd/buck-out/v2/gen/fbsource/xplat/js/tools/flow-schema/__flow-schema__bin_build__/0a63598ffadb2c1e/out/flow-schema__bin_build.zip/node_modules/react-native/codegen/src/parsers/parsers-commons.js:845:16
at guard (/re_cwd/buck-out/v2/gen/fbsource/xplat/js/tools/flow-schema/__flow-schema__bin_build__/0a63598ffadb2c1e/out/flow-schema__bin_build.zip/node_modules/react-native/codegen/src/parsers/utils.js:50:14)
at /re_cwd/buck-out/v2/gen/fbsource/xplat/js/tools/flow-schema/__flow-schema__bin_build__/0a63598ffadb2c1e/out/flow-schema__bin_build.zip/node_modules/react-native/codegen/src/parsers/parsers-commons.js:825:12
at Array.map (<anonymous>)
at buildModuleSchema (/re_cwd/buck-out/v2/gen/fbsource/xplat/js/tools/flow-schema/__flow-schema__bin_build__/0a63598ffadb2c1e/out/flow-schema__bin_build.zip/node_modules/react-native/codegen/src/parsers/parsers-commons.js:811:3)
at /re_cwd/buck-out/v2/gen/fbsource/xplat/js/tools/flow-schema/__flow-schema__bin_build__/0a63598ffadb2c1e/out/flow-schema__bin_build.zip/node_modules/react-native/codegen/src/parsers/parsers-commons.js:583:9
at guard (/re_cwd/buck-out/v2/gen/fbsource/xplat/js/tools/flow-schema/__flow-schema__bin_build__/0a63598ffadb2c1e/out/flow-schema__bin_build.zip/node_modules/react-native/codegen/src/parsers/utils.js:50:14)
at buildSchemaFromConfigType (/re_cwd/buck-out/v2/gen/fbsource/xplat/js/tools/flow-schema/__flow-schema__bin_build__/0a63598ffadb2c1e/out/flow-schema__bin_build.zip/node_modules/react-native/codegen/src/parsers/parsers-commons.js:582:24)
at buildSchema (/re_cwd/buck-out/v2/gen/fbsource/xplat/js/tools/flow-schema/__flow-schema__bin_build__/0a63598ffadb2c1e/out/flow-schema__bin_build.zip/node_modules/react-native/codegen/src/parsers/parsers-commons.js:648:10)
at FlowParser.parseString (/re_cwd/buck-out/v2/gen/fbsource/xplat/js/tools/flow-schema/__flow-schema__bin_build__/0a63598ffadb2c1e/out/flow-schema__bin_build.zip/node_modules/react-native/codegen/src/parsers/flow/parser.js:131:12)
at getSchemasForFiles (/re_cwd/buck-out/v2/gen/fbsource/xplat/js/tools/flow-schema/__flow-schema__bin_build__/0a63598ffadb2c1e/out/flow-schema__bin_build.zip/fb-tools/flow-schema/schema/getSchemasForFiles.js:101:51)
at TypegenSchemaBuilder.addHackyInputsForReactNativeOnly (/re_cwd/buck-out/v2/gen/fbsource/xplat/js/tools/flow-schema/__flow-schema__bin_build__/0a63598ffadb2c1e/out/flow-schema__bin_build.zip/fb-tools/flow-schema/schema/TypegenSchema.js:94:5)
at createTypegenSchema (/re_cwd/buck-out/v2/gen/fbsource/xplat/js/tools/flow-schema/__flow-schema__bin_build__/0a63598ffadb2c1e/out/flow-schema__bin_build.zip/fb-tools/flow-schema/commands/ota-safety.js:158:42)
at Object.handler (/re_cwd/buck-out/v2/gen/fbsource/xplat/js/tools/flow-schema/__flow-schema__bin_build__/0a63598ffadb2c1e/out/flow-schema__bin_build.zip/fb-tools/flow-schema/commands/ota-safety.js:222:25)
at /re_cwd/buck-out/v2/gen/fbsource/xplat/js/tools/flow-schema/__flow-schema__bin_build__/0a63598ffadb2c1e/out/flow-schema__bin_build.zip/node_modules/yargs/build/index.cjs:1:8993
at j (/re_cwd/buck-out/v2/gen/fbsource/xplat/js/tools/flow-schema/__flow-schema__bin_build__/0a63598ffadb2c1e/out/flow-schema__bin_build.zip/node_modules/yargs/build/index.cjs:1:4956)
at _.handleValidationAndGetResult (/re_cwd/buck-out/v2/gen/fbsource/xplat/js/tools/flow-schema/__flow-schema__bin_build__/0a63598ffadb2c1e/out/flow-schema__bin_build.zip/node_modules/yargs/build/index.cjs:1:8962)
at _.applyMiddlewareAndGetResult (/re_cwd/buck-out/v2/gen/fbsource/xplat/js/tools/flow-schema/__flow-schema__bin_build__/0a63598ffadb2c1e/out/flow-schema__bin_build.zip/node_modules/yargs/build/index.cjs:1:9604)
at _.runCommand (/re_cwd/buck-out/v2/gen/fbsource/xplat/js/tools/flow-schema/__flow-schema__bin_build__/0a63598ffadb2c1e/out/flow-schema__bin_build.zip/node_modules/yargs/build/index.cjs:1:7231)
at [runYargsParserAndExecuteCommands] (/re_cwd/buck-out/v2/gen/fbsource/xplat/js/tools/flow-schema/__flow-schema__bin_build__/0a63598ffadb2c1e/out/flow-schema__bin_build.zip/node_modules/yargs/build/index.cjs:1:58544)
at te.parse (/re_cwd/buck-out/v2/gen/fbsource/xplat/js/tools/flow-schema/__flow-schema__bin_build__/0a63598ffadb2c1e/out/flow-schema__bin_build.zip/node_modules/yargs/build/index.cjs:1:40483)
at run (/re_cwd/buck-out/v2/gen/fbsource/xplat/js/tools/flow-schema/__flow-schema__bin_build__/0a63598ffadb2c1e/out/flow-schema__bin_build.zip/fb-tools/flow-schema/index.js:22:3)
at Object.<anonymous> (/re_cwd/buck-out/v2/gen/fbsource/xplat/js/tools/flow-schema/__flow-schema__bin_build__/0a63598ffadb2c1e/out/flow-schema__bin_build.zip/fb-tools/flow-schema/index.js:42:1)
at Module._compile (node:internal/modules/cjs/loader:1730:14)
at Object..js (node:internal/modules/cjs/loader:1895:10)
at Module.load (node:internal/modules/cjs/loader:1465:32)
at Function._load (node:internal/modules/cjs/loader:1282:12)
at TracingChannel.traceSync (node:diagnostics_channel:322:14)
at wrapModuleLoad (node:internal/modules/cjs/loader:235:24)
at Function.executeUserEntryPoint [as runMain] (node:internal/modules/run_main:171:5)
at Object.run (/re_cwd/buck-out/v2/gen/fbsource/xplat/third-party/node/node-zip/__module__/84c2dad32661840d/out/run.js:202:10)
at Object.<anonymous> (/re_cwd/buck-out/v2/gen/fbsource/xplat/third-party/node/node-zip/__module__/84c2dad32661840d/out/run.js:210:11)
at Module._compile (node:internal/modules/cjs/loader:1730:14)
at Object..js (node:internal/modules/cjs/loader:1895:10)
at Module.load (node:internal/modules/cjs/loader:1465:32)
at Function._load (node:internal/modules/cjs/loader:1282:12)
at TracingChannel.traceSync (node:diagnostics_channel:322:14)
at wrapModuleLoad (node:internal/modules/cjs/loader:235:24) {
nodes: [
{
type: 'GenericTypeAnnotation',
loc: [Object],
id: [Object],
typeParameters: null,
range: [Array]
}
]
}
```
Fixing it in this diff
Reviewed By: SamChou19815
Differential Revision: D89519620
fbshipit-source-id: 5adcc305e9a7c2277122ccf3f446e0e5488fedae
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/54925
The lint is triggered in D89415612. Not sure what those file do but it seems a good fix
Changelog: [General][Added] Support parsing `Readonly` for the new Flow utility types
Reviewed By: SamChou19815
Differential Revision: D89418629
fbshipit-source-id: 34a2776711155dbd52046d55af18104e2eb32322
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/54924
The lint is triggered in D89415612. Not sure what those file do but it seems a good fix
Changelog: [General][Added] Support parsing `ReadonlyArray` for the new Flow utility types
Reviewed By: SamChou19815
Differential Revision: D89418033
fbshipit-source-id: ef227b344a693ec47dea86bbf34e0af17bad25fd
Rubén Norte