Summary:
Changelog: [Internal][iOS] - Enable stub modern CDP backend in Bridgeless behind a feature flag
Minimally integrates the stub native CDP backend implementation (D50936932) into iOS Bridgeless.
This integration registers itself as a "Modern" target (D50967794, D50967795) to instruct `inspector-proxy` to disable its CDP hacks related to source map fetching, reloads, etc. This gives us a mostly-clean slate on which to develop and test native CDP functionality.
Pull Request resolved: https://github.com/facebook/react-native/pull/42393
Test Plan:
1. `js1 run`
2. Enable the modern CDP backend by grafting D52844391
3. Enable Bridgeless in RNTester by grafting D52910646
4. `buck2 install rntester-ios`
5. Dev Menu -> Open Debugger
6. Observe console message self-identifying the backend + iOS Bridgeless
7. Observe that the debugger stays connected when the app is reloaded (albeit without doing anything very interesting just yet)
{F1329876835}
Reviewed By: huntie
Differential Revision: D50936931
Pulled By: motiz88
fbshipit-source-id: ff8f919d0370266aea2916da349520bc76d690ab
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42294
This changes enables the Fabric Intrerop Layer automatically for all the users.
Practically I'm removing the fallback `ComponentDescriptor` inside the `ComponentDescriptorRegistry` so that if a component hasn't been automatically registered by a user, instead of showing the UnimplementedView, it loads a `UnstableLegacyViewManagerAutomaticComponentDescriptor`.
This ComponentDescriptor is built starting from the legacy component name, and responds with correct `ComponentName` and `ComponentHandle` (similarly to the `UnstableLegacyViewManagerInteropComponentDescriptor` but without using C++ templates).
Changelog:
[Internal] [Changed] - Fabric Automatic Interop for Android
Reviewed By: sammy-SC
Differential Revision: D52663244
fbshipit-source-id: f466486c638bb1362ef59128cd69bb9731bb9739
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42402
Now that we have 2 top level directories for JS files in the `react-native` package, we need to choose where to put the native module and native component specs, because our current infra only supports a single directory.
The options we had are:
1. Keep specs in the current directory (`Libraries`). This is a problem because it encourages us to keep adding modules in this "deprecated" directory.
2. Move specs to the new `src` directory. This requires moving the current files, but from now only we can create new specs in a private directory.
3. Modify the infra to allow multiple directories. This changes the public API for something it's likely only going to be used here.
In this PR I went for option 2) because it's the most future-proof, even though it requires a little bit more work now. I created a script to automatically copy all the specs for modules and components to `src/private/specs/components` and `src/private/specs/modules`, and changed their current locations to serve as a proxy for the new location (to avoid breaking a potentially public API).
`src/private/specs` isn't meant to be their final location. We should probably still colocate native module/component specs with the rest of their code, but we can do so when we move the code from `Libraries` to `src/private`.
Changelog: [internal]
Reviewed By: cortinico
Differential Revision: D52919566
fbshipit-source-id: 6de8a2d2b6077e4f884386567721c6bd2b88a5d3
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42386
The new DOM APIs are completely private at the moment, so they make them a good candidate to test the new directory structure (and make sure everything works correctly in CI, etc.). This moves those files to `src/private/dom`.
Changelog: [internal]
Reviewed By: huntie
Differential Revision: D52875998
fbshipit-source-id: c6c96eedcc54d47e3afff98fa2d912f9d83f3460
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42385
This adds support for having JS files in a `src` directory within the `react-native` package. The plan is to have 2 subdirectories there:
* `react-native/src/private` for private modules, with any nested directories (e.g.: `react-native/src/private/dom/nodes/ReadOnlyNode.js`).
* `react-native/src/public` for public modules, without nested directories. The plan is that the individual modules created in this directory will be public through the index module or directly via something like `react-native/View` (mapped to `react-native/src/public/View`, or a `dist` directory in the published npm package—details TBD).
The enforcement of private modules being inaccessible from outside the `react-native` package will be added soon by huntie.
Changelog: [internal]
Reviewed By: huntie
Differential Revision: D52875999
fbshipit-source-id: 914ed806f2cb86857e2cb7b760292c2190b5b14e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42585
Just a minor bump of AGP to 8.2.1
Changelog:
[Internal] [Changed] - Bump AGP to 8.2.1
Reviewed By: NickGerleman
Differential Revision: D52912324
fbshipit-source-id: 2856861f2ccedb3470a0fa548a31dd36252924c3
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42131
X-link: https://github.com/facebook/yoga/pull/1534
Now that the storage method is a hidden implementation detail, this changes the underlying data structure used to store styles, from `CompactValue` (a customized 32-bit float with tag bits), to `StyleValuePool`.
This new structure operates on 16-bit handles, and a shared small buffer. The vast majority of real-world values can be stored directly in the handle, but we allow arbitrary 32 bit (and soon 64-bit) values to be stored, where the handle then becomes an index into the styles buffer.
This results in a real-world memory usage win, while also letting us store the 64-bit values we are wanting to use for math function support (compared to doubling the storage requirements).
This does seem to make style reads slower, which due to their heavy frequency, does have a performance impact observable by synthetics. In an example laying out a tree of 10,000 nodes, we originally read from `StyleValuePool` 2.4 million times.
This originally resulted in a ~10% regression, but when combined with the changes in the last diff, most style reads become simple bitwise operations on the handle, and we are actually 14% faster than before.
| | Before | After | Δ |
| `sizeof(yoga::Style)` | 208B | 144B | -64B/-31% |
| `sizeof(yoga::Node)` | 640B | 576B | -64B/-10% |
| `sizeof(YogaLayoutableShadowNode) ` | 920B | 856B | -64B/-7% |
| `sizeof(YogaLayoutableShadowNode) + sizeof(YogaStylableProps)` | 1296B | 1168B | -128B/-10% |
| `sizeof(ViewShadowNode)` | 920B | 856B | -64B/-7% |
| `sizeof(ViewShadowNode) + sizeof(ViewShadowNodeProps)` | 2000B | 1872B | -128B/-6% |
| "Huge nested layout" microbenchmark (M1 Ultra) | 11.5ms | 9.9ms | -1.6ms/-14% |
| Quest Store C++ heap usage (avg over 10 runs) | 86.2MB | 84.9MB | -1.3MB/-1.5% |
Reviewed By: joevilches
Differential Revision: D52223122
fbshipit-source-id: 990f4b7e991e8e22d198ce20f7da66d9c6ba637b
Summary:
A first step in my work on https://github.com/react-native-community/discussions-and-proposals/issues/695
De-duplicate the code for creating `Spannable` on Android. I'm planning to add quite serious new features to this module. This would be really hard with the current level of code duplication.
## Changelog:
[INTERNAL] [CHANGED] - De-duplicate building `Spannable` on Android
Pull Request resolved: https://github.com/facebook/react-native/pull/39630
Test Plan: I tried to ensure that the refactored code is relatively easy to prove to be equivalent to the original duplicated one, but there's always a risk of a human mistake in this process. So far, I have been testing this by ensuring that nothing broke in the `Text` example section in RNTester.
Reviewed By: mdvacca
Differential Revision: D51016244
Pulled By: NickGerleman
fbshipit-source-id: e9f873c01b2af0685c7b0943aebea170c997d22e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42399
Mark CallInvokerHolder APIs as FrameworkAPI only, these APIs are meant to be used only for partner frameworks
changelog: [internal] internal
Reviewed By: cortinico
Differential Revision: D52913739
fbshipit-source-id: 5a2c8be629e90a33e0cfb66b28e0171c71f5940d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42387
Changelog: [Internal]
Documents that it's legal for a Page's connection function to return null, and adds new logic to `InspectorPackagerConnection` (NOTE: to the C++ implementation *only*) to handle this case without crashing.
The legacy RN CDP backend (`ConnectionDemux`) has a case similar to this that causes crashes depending on the timing of connection requests.
Reviewed By: cortinico
Differential Revision: D52905490
fbshipit-source-id: 2102adc859d1509647a31f92737a1e164781fadf
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42384
Changelog: [Internal]
Similar to D52894171, adds a console log message identifying the specific CDP backend integration, based on an optional `SessionMetadata` object passed to `PageTarget::connect()`. This is helpful during development+rollout as we will have 4+ such call sites (iOS/Android, Bridge/Bridgeless).
Reviewed By: huntie
Differential Revision: D52905488
fbshipit-source-id: d26aae1d07c2c42965498a81f03d826de98fa222
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42383
Changelog: [Internal]
During development / experimental rollout of the modern CDP backend, it can be helpful to have a user-visible message that makes it clear that the new backend is in use. Here, we add one using the [`Log.entryAdded`](https://chromedevtools.github.io/devtools-protocol/tot/Log/#type-LogEntry) CDP event. We also add some styling using [ANSI escape sequences](https://developer.chrome.com/docs/devtools/console/format-style#style-ansi) to make the message stand out from normal application logs.
We could have used [`Runtime.consoleAPICalled`](https://chromedevtools.github.io/devtools-protocol/tot/Runtime/#event-consoleAPICalled) instead, but:
1. `Runtime.consoleAPICalled` requires an `executionContextId` which is not available at the `Page` level (it is a concept that's managed closer to the instance/VM), and it's slightly cleaner if we don't have to send a fake context ID.
2. It's slightly easier to follow the CDP dispatching logic / grep for relevant code if we use `Log` for "system logs" (from the Page) and reserve `Runtime` for real application logs from the instance/VM.
NOTE: We'll probably want to remove this before the stable release.
Reviewed By: huntie
Differential Revision: D52894171
fbshipit-source-id: 3208e01f2ee31acef2e8cd58767f40ad724c9a39
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42397
Changelog: [Internal]
Adds a stub `PageTarget` class to serve as the entry point to the modern CDP backend in React Native.
The primary method exposed by `PageTarget` is `connect()` which is designed to fit directly as a connection callback passed to `InspectorPackagerConnection::addPage()`. This constructs a `PageTargetSession` containing a `PageAgent` where the actual CDP message handling/routing will occur. For now, `PageAgent` implements no CDP methods, and always responds with a "not implemented" error.
Basic unit tests are included, though we might want to migrate to a more integration-style test suite (with fewer mocks and real bindings to RN) once we've implemented more of the protocol.
## What is a Page
In Chrome's implementation of CDP, a Page represents a single browser tab. A Chrome DevTools session connects to one Page at a time (though it can potentially inspect multiple JavaScript contexts owned by that Page, such as those found in frames and workers).
In our system, a Page will correspond 1:1 to React Native's concept of a *Host* (implemented as `RCTHost`, `RCTBridge`, `ReactHostImpl` or `ReactInstanceManager`, depending on the platform). In all cases, the Host is the object that has a stable identity across reloads, and manages the lifetime of an *Instance* where the JSVM and other application state lives. There can be multiple Hosts in a React Native process, though this is somewhat unusual; those would be treated as independent "tabs" from the perspective of the debugger.
NOTE: The concepts of Target, Session and Agent are new (to this codebase) and are *broadly* inspired by the [corresponding Chromium / V8 concepts](https://chromium.googlesource.com/chromium/src/+/master/third_party/blink/public/devtools_protocol/#Agents_Targets-and-Sessions), though some details differ.
## Next steps
Each core platform implementation in React Native (iOS Bridgeless, iOS Bridge, Android Bridgeless, Android Bridge), as well as out-of-tree platforms that want to support the new debugger, will need to create and register a `PageTarget` instance. We'll do this piecemeal in subsequent diffs.
We'll also gradually add APIs and logic to `PageTarget` / `PageAgent` to allow us to implement some "interesting" CDP methods - some of them directly (e.g. handling reload commands) and others by dispatching to nested agents (e.g. a JS debugging agent powered by Hermes).
Reviewed By: huntie
Differential Revision: D50936932
fbshipit-source-id: ebe5856d7badb361d4971dd9aabeb9982f8aed1b
Summary:
Recently inside React Native Community CLI we added bumping Yarn version inside `init` command, more information here: https://github.com/react-native-community/cli/pull/2134. In this Pull Request I added required rules in `.gitignore` for new projects created.
## Changelog:
[GENERAL] [ADDED] - Add Yarn files to `.gitignore` in template
Pull Request resolved: https://github.com/facebook/react-native/pull/42313
Test Plan:
1. Follow [Contributing guide](https://github.com/react-native-community/cli/blob/main/CONTRIBUTING.md) from React Native Community CLI repository to setup locally newest version of CLI.
2. Run this command:
```sh
node /path/to/react-native-cli/packages/cli/build/bin.js init --template path/to/template
```
3. Appropriate should be ignored.
Reviewed By: NickGerleman
Differential Revision: D52907962
Pulled By: cortinico
fbshipit-source-id: f12dce8836e7e94257f8c690434b11227aa46446
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42254
X-link: https://github.com/facebook/yoga/pull/1550
This change aims to simplify how we resolve edges. This operation happens many, many times, and has gotten complex and slow when paired with StyleValuePool.
This starts reshaping so that `yoga::Style` can resolve a style prop for a given edge. This is closer to the ideal computed style API to avoid recalcing this so many times, but doesn't address that.
This relies on removing the errata related to row-reverse, and cleans up the removal started in the last change.
This has no measurable perf effect under CompactValue, but has a >10% uplift in perf when using StyleValueHandle, where we can trivially check if a handle points to a defined value without resolving it, but only within `yoga::Style` since we don't expose the handle outside of it.
More quantifiably, we go from 2.35 million StyleValuePool reads to 993k. The rest are checks on the handle.
Reviewed By: joevilches
Differential Revision: D52605596
fbshipit-source-id: 0b366963a899e376f99ce3d75cd5f14a25d60cec
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42314
X-link: https://github.com/facebook/yoga/pull/1555
The next diff moves a bunch of methods to `yoga::Style`. This renames the function to be a tad bit shorter, for more readable callsites. It also makes it more consistent with style property getters.
Changelog: [Internal]
Reviewed By: rozele
Differential Revision: D52803393
fbshipit-source-id: 557df34a9f0fb0ee42ad23b1fda99c1e0eb1d4e3
Summary:
This removes the 4 ineffective and redundant entries from the `exclude` list in `tsconfig.json` (`typescript-config` package).
These entries have no effect as they are relative to the typescript-config package. Explained in detail here: https://github.com/tsconfig/bases/issues/207
A newly generated RN app shows this config:
```
$ yarn tsc --showConfig | grep -A 5 exclude
"exclude": [
"node_modules/tsconfig/react-native/node_modules",
"node_modules/tsconfig/react-native/babel.config.js",
"node_modules/tsconfig/react-native/metro.config.js",
"node_modules/tsconfig/react-native/jest.config.js"
]
```
Clearly, none of these files exist, therefore to remove ambiguity and reduce the complexity of the config, they should be removed.
## Changelog:
[GENERAL] [REMOVED] - Remove ineffective excludes from typescript-config
Pull Request resolved: https://github.com/facebook/react-native/pull/42375
Test Plan:
- Create new RN app (`npx react-native init`), install dependencies, run `yarn tsc`
- It works
- Recreate config, but _without_ the `exclude` section
- Everything works exactly the same
Reviewed By: huntie
Differential Revision: D52904713
Pulled By: NickGerleman
fbshipit-source-id: d1d6f65b164053f9a1e611022178ced032a38aef
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42390
Changelog: [Internal]
Add an optional mechanism for inspector pages to be registered with the "modern" or "legacy" type (defaulting to legacy). This is aligned with the inspector-proxy implementation of the `type` property in D50967795.
NOTE: This mechanism is experimental, only takes effect if `InspectorPackagerConnection.cpp` is in use, and will likely evolve before the RN 0.74 branch cut.
Reviewed By: huntie
Differential Revision: D50967794
fbshipit-source-id: e7521267dfc0b0811c4d369e63f4f1756ce22d60
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42380
Changelog: [Internal]
Makes it explicitly legal to call `IRemoteConnection`'s methods from any thread when used as part of the C++ implementation of `InspectorPackagerConnection`.
Implementation details:
* This relies on `InspectorPackagerConnectionDelegate::scheduleCallback` being thread-safe and handling any necessary synchronisation (which is already required for the existing `reconnect()` use case).
* We add *very basic* tracking of *sessions* within `InspectorPackagerConnection` to make sure events don't leak from one `RemoteConnection` instance to the next.
* In the future we'll want to build on this to properly allow multiple concurrent sessions to a single page. That's not the primary goal here though.
Reviewed By: rubennorte
Differential Revision: D52807388
fbshipit-source-id: 6900386a1f047c99f15dc91597f308c82adf5281
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42362
This undos a change of CallInvokerHolder bringing it back in the public package: https://github.com/facebook/react-native/commit/b7191cde4e36
The problem is that if a developer wants to use the C++ CallInvokerHolder to schedule work on the JS thread from C++, they're forced to import the `.internal`
Java/Kotlin class.
Plus this is going to be a massive breaking change for the ecosystem:
https://github.com/search?type=code&q=%2Fimport.*CallInvokerHolderImpl%2F
So unless we come with a clear deprecation/replacement path, I'm undoing this change for now.
Changelog:
[Internal] [Changed] - Undo move of CallInvokerHolder to `.internal`
Reviewed By: cipolleschi
Differential Revision: D52873256
fbshipit-source-id: 900c3170ed2100ec706b03112bc23a0ba0171bcc
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42358
Just converting those two classes to Kotlin as I was going over them.
Changelog:
[Internal] [Changed] - Convert InteropEvent and InteropEventEmitter to Kotlin
Reviewed By: javache
Differential Revision: D52869490
fbshipit-source-id: 2d585dd3d21dc89c5e55de645e9519d36f67b849
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42360
In cases where you merge out-of-tree platforms like react-native-windows with react-native mobile JS files, codegen awareness of the Windows suffix is useful. This helps prevent the creation of generated code for iOS and Android in mixed out-of-tree platform folders.
## Changelog
[Internal]
Reviewed By: mdvacca
Differential Revision: D52873212
fbshipit-source-id: ad6b1471e63d68057f54c79141123fb15f8aab5e
Summary:
X-link: https://github.com/facebook/yoga/pull/1558
Pull Request resolved: https://github.com/facebook/react-native/pull/42318
AbsolutePositioning -> AbsolutePositioningCatchAll
A bit more clear. This errata is for various issues with positioning absolute nodes. There really isn't a clear description as to what specifically this enables/disables, so I just opted to say "catch all" to indicate that this controls various bugs
Reviewed By: NickGerleman
Differential Revision: D52820117
fbshipit-source-id: 80b77832baf65e68e57ca523c418422dd346ef0f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42317
Added a complicated zIndex test and corresponding screenshot test for it.
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D52439963
fbshipit-source-id: 54bc8cfc9aa2e3c985279fe43027b3db88057c68
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42316
We need to change the typing to allow for 'static'. An issue here is that Paper will not have `static` due to missing z-index logic. Unfortunately, we cannot create a fabric-only version of the typing as we cannot have conditional elements of the same name in ts. To remedy this we took out the parsing of the string 'static' in Paper. Instead we will just emit a warning and default to `relative`.
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D51431524
fbshipit-source-id: 0444b2f8432f172b2e8a084b307b0e624dba8085
Summary:
X-link: https://github.com/facebook/yoga/pull/1556
Pull Request resolved: https://github.com/facebook/react-native/pull/42315
Since we aim to ship static to all users of yoga (not just XPR), we need to remove the errata that is gating most of the features. This should be a non breaking change. To ensure that, I added a new errata which, if on, will use the inner size of the containing node as the containing block. This is how it has been for a while and resolving this is risky and time consuming so for the time being we will stick with that.
Reviewed By: NickGerleman
Differential Revision: D52706161
fbshipit-source-id: 30a93f29cb0d97b20b2947eaa21f36cdc78c4961
Summary:
X-link: https://github.com/facebook/yoga/pull/1549
Pull Request resolved: https://github.com/facebook/react-native/pull/42253
This experimental feature is always false, and with the next diff I will be deleting the branch that actually calls into this. Separating this diff out to simplify the review process.
Reviewed By: NickGerleman
Differential Revision: D52705765
fbshipit-source-id: 705f4aa297eae730af9b44753eb01c9dec385dcf
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42308
Changelog: [Internal]
Guarantees cleanup of `ILocalConnection` when the associated page is unregistered from `IInspector`.
NOTE: This only applies to the C++ version of `InspectorPackagerConnection`. The legacy pure-Java and pure-ObjC implementations are of this class are unchanged.
In the upcoming modern CDP backend architecture, this will help guarantee the validity of Target references (specifically PageTarget) held by Agents (specifically PageAgent), without introducing unnecessary shared ownership and dynamism.
Reviewed By: hoxyq
Differential Revision: D52786331
fbshipit-source-id: 162425d6435246a95ac9c076bc5c59a34f331f16
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42304
Changelog: [Internal]
Light refactor of `InspectorImpl`'s storage from two separate maps (one of them with tuples for values!) to a single map of objects.
Reviewed By: hoxyq
Differential Revision: D52786335
fbshipit-source-id: a49466ed7189fd032e486319bbdf77097a30885f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42301
Changelog: [Internal]
To simplify testing and rolling out the modern CDP backend in React Native, let's require the use of the C++ version of `InspectorPackagerConnection` whenever the modern CDP backend is in use, regardless of the `InspectorPackagerConnection` rollout setting.
Reviewed By: hoxyq
Differential Revision: D52786334
fbshipit-source-id: 5c12794e3faa2c094a23f69a5677f66905d1763e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42355
`RemoveDeleteTreeUIFrameCallback` operated directly on the view to clean up its children, which does not correctly account for subviews which have been clipped because they're outside the visible frame.
Changelog: [Android][Added] Added `removeAllViews` to IViewGroupManager.
Reviewed By: jehartzog, sammy-SC
Differential Revision: D52834835
fbshipit-source-id: fb7f07a17d07467eecd3ce9721afc2f3abcc0caa
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42302
Changelog: [Internal][Added] Support launching experimental debugger frontend for CDP targets marked as "modern"
See the definition of "modern" targets in D50967795.
Reviewed By: hoxyq
Differential Revision: D52786332
fbshipit-source-id: 13718e9ddf3ec050049ef7ec9a77f6cf1a7f82ee
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42303
Changelog: [Internal]
Adds a coarse-grained mechanism to `inspector-proxy` for distinguishing between legacy and modern debug targets. The guiding principles are:
1. `inspector-proxy` does not interfere in the CDP message stream between the debugger frontend and a modern target, or in the lifecycle of a target.
2. Legacy runtimes (current React Native, React Native Desktop, etc) that rely on `inspector-proxy`'s existing invasive semantics must continue to work seamlessly for now. We'll decide on the right time to deprecate/remove this legacy code in the future.
NOTE: This is an experimental addition to the proxy protocol that may be replaced at any time.
Reviewed By: hoxyq
Differential Revision: D50967795
fbshipit-source-id: bb9c39a8fe755ef3661e2c61507dd324d8dc8894
Summary:
Added `--custom-resolver-options` to `--bundle` command. This options is also [available](https://github.com/facebook/metro/blob/main/docs/CLI.md#options) in Metro's CLI.
## Changelog:
[INTERNAL] [ADDED] - Add `--resolver-options` to `bundle` command
Pull Request resolved: https://github.com/facebook/react-native/pull/42333
Test Plan:
1. Build all packages by running `yarn build` in the root
2. Go to `packages/rn-tester` and run `npx react-native bundle --custom-resolver-options key=value` and the options should be passed to the Config.
Reviewed By: blakef
Differential Revision: D52869452
Pulled By: huntie
fbshipit-source-id: 9a2c2d94b72cfb47477cf58b9c0472c5a8551c84
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42282
Changelog: [Internal] `inspector-proxy` now assumes each app will report pages with locally unique IDs.
In order to simplify some upcoming logic changes in `inspector-proxy`, in this diff we begin to enforce the assumption that each app ( = platform-specific implementation of `InspectorPackagerConnection`) assigns a locally unique ID to each inspector page. The inspector proxy will silently drop page descriptors that have conflicting IDs, and log a message to `debug()`.
NOTE: As an implementation detail, integrators may use `DEBUG=Metro:InspectorProxy` to see debug messages from `inspector-proxy`.
Reviewed By: huntie
Differential Revision: D50969752
fbshipit-source-id: a4e6faa91d97594fc5343ce4bee66233523cd175
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42271
Changelog: [Internal]
Adds a util function to determine the `TurboModuleMethodValueKind` based on the `jsi:Value` type
Reviewed By: javache
Differential Revision: D52761045
fbshipit-source-id: de937cda67198aad962e63f41ccd42be6c00c0b8
Moti Zilberman
Nicola Corti
Rubén Norte
Erica Klein
Nick Gerleman
Jakub Trzebiatowski
David Vacca
Moti Zilberman
szymonrybczak
Fabrizio Cucci
Oskar Kwaśniewski
Frieder Bluemle
Alex Hunt
Christoph Purrer
Samuel Susla
Eric Rozell
Joe Vilches
Pieter Vanderwerff
Pieter De Baets
Tommy Nguyen
Luna Wei