Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/37471
## Changes
Make the TurboModule system use NativeMethodCallInvoker::invokeSync to schedule synchronous native module method calls. Functionally, this changes nothing.
## What this unlocks
In the future (i.e: D45924977), the TurboModule interop layer will implement NativeMethodCallInvoker::invokeSync to dispatch the constantsToExport method call on to the main queue, when the legacy module requires main queue setup.
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D45924976
fbshipit-source-id: 0760827ab3ed72c2f3af0da4e4f2af0e39b639cb
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/37473
## Context
The TurboModule system uses a CallInvoker interface to schedule JavaScript → native, and native → JavaScript calls.
## Problem
JavaScript → native and native → JavaScript calls are different. They can have different behaviours/properties. And, in the future, we might want to evolve them differently. e.g:
- JavaScript → native **always** have a method name. Native → JavaScript calls don't.
- Native → JavaScript can have priorities, since D41492849. JavaScript → native don't.
## Changes
Instead of tying both types of calls to the CallInvoker abstraction, this diff creates a **separate** abstraction for Native → JavaScript calls: NativeMethodCallInvoker.
This way, we can evolve both abstractions separately over time:
- We can evolve the CallInvoker abstraction to suit the needs of JavaScript → native calls.
- We can evolve the NativeMethodCallInvoker abstraction to suite the needs of native → JavaScript calls.
This ultimately makes TurboModule system more extensible.
## Motivation
For the TurboModule interop layer on iOS, React Native needs to execute the "constantsToExport" method on the main queue, when the module requires main queue setup. (implementation: D45924977).
The simplest way to implement this behaviour is to introduce a `methodName` to CallInvoker, and customize the legacy module's CallInvoker::invokeSync method, like so:
```
void invokeSync(std::string methodName, std::function<void()> &&work) override
{
if (requiresMainQueueSetup_ && methodName == "getConstants") {
__block auto retainedWork = std::move(work);
RCTUnsafeExecuteOnMainQueueSync(^{
retainedWork();
});
return;
}
work();
}
```
But, customizing CallInvoker to introduce a `methodName` parameter doesn't make sense: Native → JavaScript calls don't necessarily have method names. So, this diff forks CallInvoker into NativeMethodCallInvoker. That way, we can customize NativeMethodCallInvoker to introduce a method name (which does make sense) and resolve this problem. For the full solution, see D45924977.
NOTE: Now that NativeMethodCallInvoker is different from CallInvoker, it might make sense to re-name CallInvoker back to JSCallInvoker.
Changelog:
[Category][Breaking] - Introduce NativeMethodCallInvoker to replace the TurboModule system's native CallInvoker
Reviewed By: javache
Differential Revision: D45891627
fbshipit-source-id: 39c3f450a290ad396b715288a50858d33ce78441
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/37520
Results in better error messages, especially when trying to copy a Value.
With this change:
```
../API/hermes/hermes.cpp: In member function ‘facebook::jsi::Value facebook::hermes::HermesRuntimeImpl::valueFromHermesValue(hermes::vm::HermesValue)’:
../API/hermes/hermes.cpp:726:31: error: use of deleted function ‘facebook::jsi::Value::Value(const facebook::jsi::Value&)’
726 | auto copy = jsi::Value(val);
| ^
In file included from ../API/hermes/hermes.h:18,
from ../API/hermes/hermes.cpp:8:
../API/jsi/jsi/jsi.h:938:18: note: ‘facebook::jsi::Value::Value(const facebook::jsi::Value&)’ is implicitly declared as deleted because ‘facebook::jsi::Value’ declares a move constructor or move assignment operator
938 | class JSI_EXPORT Value {
| ^~~~~
```
Before:
```
In file included from ../API/hermes/hermes.h:18,
from ../API/hermes/hermes.cpp:8:
../API/jsi/jsi/jsi.h: In instantiation of ‘facebook::jsi::Value::Value(T&&) [with T = facebook::jsi::Value&]’:
../API/hermes/hermes.cpp:726:31: required from here
../API/jsi/jsi/jsi.h:963:49: error: no matching function for call to ‘facebook::jsi::Value::kindOf(facebook::jsi::Value&)’
963 | /* implicit */ Value(T&& other) : Value(kindOf(other)) {
| ~~~~~~^~~~~~~
../API/jsi/jsi/jsi.h:1176:30: note: candidate: ‘static constexpr facebook::jsi::Value::ValueKind facebook::jsi::Value::kindOf(const facebook::jsi::Symbol&)’
1176 | constexpr static ValueKind kindOf(const Symbol&) {
| ^~~~~~
../API/jsi/jsi/jsi.h:1176:37: note: no known conversion for argument 1 from ‘facebook::jsi::Value’ to ‘const facebook::jsi::Symbol&’
1176 | constexpr static ValueKind kindOf(const Symbol&) {
| ^~~~~~~~~~~~~
../API/jsi/jsi/jsi.h:1179:30: note: candidate: ‘static constexpr facebook::jsi::Value::ValueKind facebook::jsi::Value::kindOf(const facebook::jsi::String&)’
1179 | constexpr static ValueKind kindOf(const String&) {
| ^~~~~~
../API/jsi/jsi/jsi.h:1179:37: note: no known conversion for argument 1 from ‘facebook::jsi::Value’ to ‘const facebook::jsi::String&’
1179 | constexpr static ValueKind kindOf(const String&) {
| ^~~~~~~~~~~~~
../API/jsi/jsi/jsi.h:1182:30: note: candidate: ‘static constexpr facebook::jsi::Value::ValueKind facebook::jsi::Value::kindOf(const facebook::jsi::Object&)’
1182 | constexpr static ValueKind kindOf(const Object&) {
| ^~~~~~
../API/jsi/jsi/jsi.h:1182:37: note: no known conversion for argument 1 from ‘facebook::jsi::Value’ to ‘const facebook::jsi::Object&’
1182 | constexpr static ValueKind kindOf(const Object&) {
| ^~~~~~~~~~~~~
../API/jsi/jsi/jsi.h:966:47: error: static assertion failed: Value cannot be implicitly move-constructed from this type
965 | std::is_base_of<Symbol, T>::value ||
| ~~~~~~~~
966 | std::is_base_of<String, T>::value ||
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~
967 | std::is_base_of<Object, T>::value,
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../API/jsi/jsi/jsi.h:966:47: note: ‘((((bool)std::integral_constant<bool, false>::value) || ((bool)std::integral_constant<bool, false>::value)) || ((bool)std::integral_constant<bool, false>::value))’ evaluates to false
../API/jsi/jsi/jsi.h:969:5: error: new cannot be applied to a reference type
969 | new (&data_.pointer) T(std::move(other));
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
```
Among other things, this puts the actual error on the consuming code where the
error is, which results in those nice red squiggles under it while typing to
tell you that you screwed up.
X-link: https://github.com/facebook/hermes/pull/526
Test Plan: This should only convert one type of compiler error to another, so existing tests should be sufficient.
Reviewed By: tmikov
Differential Revision: D46005344
Pulled By: neildhar
fbshipit-source-id: 194e0483177770df578cb864281d66c88d4cdb7e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/37519
While these tests currently happen to pass, actually trying to
instantiate `fromJs` fails to compile. I suspect this is attributable
to some difference in how `fromJs` is instantiated in evaluated and
unevaluated contexts. That is since `supportsFromJs` only instantiates
it in an unevaluated context (in a decltype), the rules are presumably
different.
It is also worth noting that the operator of up-casting JSI types to
`jsi::Value` is explicitly deleted in `Converter`, which suggests
that the conversion this test is checking for may be intentionally
unsupported.
For now, since `fromJs` cannot actually be used with the given
parameters, delete the test.
This unblocks a later diff which changes the constructor of
`jsi::Value` such that
`std::is_convertible<jsi::Object &, jsi::Value>` is no longer true (the
conversion is never allowed, but is currently enforced by
`static_assert` ). With that change
`supportsFromJs<jsi::Value, jsi::Object>` also becomes false.
Changelog: [Internal]
Reviewed By: javache, cortinico
Differential Revision: D46059603
fbshipit-source-id: 01ede3cadb74ce6a3cd9d5d3ce34b8648fd88de7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/37517Fixes#35778
We got reports of regressions on `useEffect` starting from 0.69+ when on Hermes.
The issue seems to be caused by a bump of the `scheduler` package from 0.20 to 0.21.
In scheduler@0.21, the method `setImmediate` gets called if available
(see https://github.com/facebook/react/pull/20834). This causes React Native to use Microtasks
which ends up in changing the semantic of useEffect.
The solution is to use the Native RuntimeScheduler properly.
On Paper specifically, we never initialized it as it's effectively initialized by the
TurboModuleManagerDelegate. Here I trigger the initialization of it on Paper as well.
Changelog:
[Android] [Fixed] - Make sure the Native RuntimeScheduler is initialized on Old Arch
Reviewed By: sammy-SC
Differential Revision: D46024807
fbshipit-source-id: d72cd774df58410467644cddeaaf37e3c227b505
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/37516
This will fail build failures from apps which are using libraries which imports
```
#include <react/renderer/graphics/conversions.h>
```
That's just a warning but our usage of `-Wall -Werror` is causing this to fail user builds.
More context on this issue here:
https://github.com/reactwg/react-native-releases/discussions/54#discussioncomment-5968545
We can revert this `-Wno-error` once we're on 0.73 as that specific #warning will be entirely
removed from the codebase.
Changelog:
[Internal] [Changed] - Add -Wno-error=cpp on App's default Cmake file
Reviewed By: dmytrorykun
Differential Revision: D46071400
fbshipit-source-id: 4937fb1255df3f2765f645dfd59f5c58526dee42
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/37513
After the monorepo migration, we started to add license headers to the template file.
This needs to be reverted, I'm doing it here.
Changelog:
[Internal] [Changed] - Do not add Meta's license header to template
Reviewed By: dmytrorykun
Differential Revision: D46070682
fbshipit-source-id: ee071d90c92e32c57698b09298a2f5cf39d3f6d7
Summary:
Currently npx has a variety of caching strategies to avoid having to pull a version of the package from a registry. These are often unexpected to our users, who may fall behind. After looking at a variety of fancy approaches to dealing with this (the high end of which was intelligently forking npx to run `npx react-native@latest <args>`, the best possible tradeoff for time and simplicity was to warn the user when they weren't running the latest release:
{F999520817}
### Problem Details
On my laptop when you run `npx <package> <arguments>` this it eventually calls [libnpmexec](https://github.com/npm/cli/tree/0783cff9653928359a6c68c8fdf30b9fd02130c9/workspaces/libnpmexec), which applies this lookup [algorithm](https://github.com/npm/cli/blob/0783cff9653928359a6c68c8fdf30b9fd02130c9/workspaces/libnpmexec/lib/index.js#L39-L41) for `package@version`:
- is package available in local modules (npm root → `~/project/node_modules/<package>`)?. **Importantly it will walk all the way down to `/` looking for `node_modules/<package>`**.
- is package available in global modules (npm root -g → `/Users/blakef/.nvm/versions/node/v17.9.0/lib/node_modules`)?
- is package available in npx cache (`~/.npm/_npx`)?
- is package available in your registry? Download to the npx cache `~/.npm/_npx/<hash>/`
At this point you'll have a cached copy, which then has its bin script run with the arguments you originally provided.
### How this works against React-Native users
Users can get their development environment into a **persistent** pickle with a bunch of unintended side-effects of npx / npm exec’s caching model:
- **It matters where you run `npx react-native`**, since it’ll default to the version of react-native in a node package's folder. This works well for us in a React Native project, but not when initializing a project outside of a package folder.
- **Global and relative node_modules really matter**. If your users runs npx react-native init and they have a version of react-native installed globally, it’ll use that version.
- If the user has a `node_modules/react-native` installation anywhere in the directory hierarchy it’ll be used. For example if I run `npx react-native init Foobar` in `/home/blakef/src/example` , npx will look for versions of react-native like this before searching globals or the npx cache:
- /home/blakef/src/example/node_modules
- /home/blakef/src/node_modules
- /home/blakef/node_modules
- /home/node_modules
- /node_modules
**nvm just makes things harder** if your user switches between versions of node it can be hard to determine if they're affected by a globally installed version. Examples include having a `.nvmrc` file in the directory they run the command which transparently switches node version (and globals location).
## Changelog:
[General][Added] - Log a warning if npx react-native uses old cached version
Pull Request resolved: https://github.com/facebook/react-native/pull/37510
Test Plan: Ran this directly from the project, defining the `npm_lifecycle_event=npx` to mock directly running using `npx`.
Reviewed By: Andjeliko
Differential Revision: D46069419
Pulled By: blakef
fbshipit-source-id: 1c1af7f639c5312760a39a0828b89b7ddf2b5fda
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/37494
I'm adding some unit tests to this function that got recently added to support TvOS
Changelog:
[Internal] [Changed] - Add tests for getDependencySubstitutions
Reviewed By: cipolleschi
Differential Revision: D46029402
fbshipit-source-id: 6099242fe9e18f1a612124bc784f90047b4ee286
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/37477
When creating a stack of several codegen fixes, a conflit generated some duplicated code we moved to the parsers from the utils.
This change removes that duplicated cone.
## Changelog:
[Genearal][Fixed] - Remove duplicated code.
Reviewed By: cortinico
Differential Revision: D45979013
fbshipit-source-id: 78cb89df81305221258e283ba5924135d498e800
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/37475
We recently landed a change with a typo in the interface declaration. We just fixed the typo
## Changelog:
[General][Fixed] - Fixed a typo in the interface declaration
Reviewed By: robhogan
Differential Revision: D45978419
fbshipit-source-id: f44dbcd5c1706b9582b997a5eb6c0a82d0e422cc
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/37481
ViewManagers inherit from BaseJavaModule so we should honour the same lifecycle for them as we do for native modules, which is to call `invalidate` / `onCatalystInstanceDestroy` when the ReactContext is destroyed. This allows the ViewManager to do any cleanup which cannot happen at the View level.
Changelog: [Android][Fixed] ViewManagers now receive an invalidate callback
Reviewed By: cortinico
Differential Revision: D45945678
fbshipit-source-id: 27c26d951b50a734c42eb033a46e599ef939e29f
Summary:
X-link: https://github.com/facebook/metro/pull/987
While working on https://github.com/facebook/react-native/pull/35786 I noticed some inconsistencies in the versioning for Babel and Flow across the monorepo. So in this PR I wanted to address that so that for 0.72 we'll have the codebase in a more consistent shape.
Happy to split in multiple PRs if needed.
## Changelog
[GENERAL] [CHANGED] - Bump Babel packages to ^7.20.0 (or closest latest release), bump flow parser to 0.206.0 in a few places that were left out from latest bump
Pull Request resolved: https://github.com/facebook/react-native/pull/35787
Test Plan: CI is green.
Reviewed By: cipolleschi
Differential Revision: D42384881
Pulled By: hoxyq
fbshipit-source-id: 21fd43391d12722cf707c3cdbbb36f49c036359d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/37381
SurfaceRegistry was a bridgeless-only concept, which hasn't actually diverged much from AppRegistry and doesn't support any new use-cases. It also causes additional complexity in terms of Logbox. Merge the logic with AppRegistry, and rewrite existing callers to AppRegistry.
Changelog: [Internal]
Reviewed By: christophpurrer
Differential Revision: D45730959
fbshipit-source-id: e2e2626c4dec8423aa097eff76cfa4d199f3a680
Summary:
For 3rd party libraries to work with a React Native fork (such as the TV repo) that uses a different Maven group for `react-android` and `hermes-android` artifacts, an additional dependency substitution is required.
## Changelog:
[Android][fixed] RNGP dependency substitutions for fork with different Maven group
Pull Request resolved: https://github.com/facebook/react-native/pull/37445
Test Plan:
- Manual tested with an existing project
- Unit tests pass
Reviewed By: rshest, dmytrorykun
Differential Revision: D45948901
Pulled By: cortinico
fbshipit-source-id: 4151a1d3616172a92c68812c3a0034c98b330d67
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/37451
It seems like starting from AGP 7.4, Android is not including the `-DANDROID` flag
anymore from the NDK toolchain.
As we do have several `#ifdef` logic that takes care of having this macro set,
I'm going to make sure it's always set for both ReactAndroid, hermes-engine
and the template.
Changelog:
[Android] [Fixed] - Make sure the -DANDROID compilation flag is always included
Reviewed By: javache
Differential Revision: D45908787
fbshipit-source-id: 07284712d7bcce73dc8ea0dffd4a9d00af4de1d2
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/37459
changelog: [internal]
Let's try to dissable manual `[CATransaction commit]`. This may reduce UI thrash in case several Fabric transactions are committed within single UIRunLoop tick.
While working on [the new architecture benchmarks](https://github.com/reactwg/react-native-new-architecture/discussions/123), with the help of instrumentation I noticed two paints on some occasions. This was happening around 50% of the time I executed a scenario. It dropped the rendering time on 5k of <Text /> from ~800ms down to ~600ms.
Also, the original reason why `[CATransaction commit]` was added has passed. It was added to make Screenshot tests less flaky but we no longer use screenshot tests.
Reviewed By: javache
Differential Revision: D45870408
fbshipit-source-id: 23112c2d92451aba40ad770ffd34f4d5f0ea585f
Summary:
[Codegen 104] This PR introduces `getResolvedTypeAnnotation` to the Parser class and implements this function in Typescript and Flow Parsers.
We also get rid of usages `resolveTypeAnnotation` from :
- `packages/react-native-codegen/src/parsers/typescript/utils.js`
- `packages/react-native-codegen/src/parsers/flow/utils.js`
and replace it with `parsers.getResolvedTypeAnnotation` as requested on https://github.com/facebook/react-native/issues/34872
bypass-github-export-checks
## Changelog:
[Internal] [Changed] - Add `getResolvedTypeAnnotation ` to Parsers and update usages.
Pull Request resolved: https://github.com/facebook/react-native/pull/37373
Test Plan: Run yarn jest react-native-codegen and ensure CI is green
Reviewed By: dmytrorykun
Differential Revision: D45865651
Pulled By: cipolleschi
fbshipit-source-id: fdce6e5059306ebe67121aa1b212e67de864bf84
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/37362
Changelog: [Internal]
this class should not be instantiated without its dependencies
Reviewed By: RSNara
Differential Revision: D45747779
fbshipit-source-id: ac2869858ad0ee67fbf9c04c58ff0a2bdf98c224
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/37444
Changelog: [Internal]
In this change, I'm removing these public notification strings that are used to listen to CMD + R reload by replacing them with a more general, lifecycle callback. Consumers can use this if there's anything in userland that they need to do once React is ready, such as doing some work with any native modules.
Reviewed By: sammy-SC
Differential Revision: D45760847
fbshipit-source-id: 2601ce083df827f79ea3f888f13fff1fc53c9564
Summary:
## Summary
Initially reported in https://github.com/facebook/react/issues/26797.
Was not able to reproduce the exact same problem, but found this case:
1. Open corresponding codepen from the issue in debug mode
2. Open components tab of the extension
3. Refresh the page
Received multiple errors:
- Warning in the Console tab: Invalid renderer id "2".
- Error in the Components tab: Uncaught Error: Cannot add node "3"
because a node with that id is already in the Store.
This problem has occurred after landing a fix in
https://github.com/facebook/react/pull/26779. Looks like Chrome is
keeping the injected scripts (the backend in this case) and we start
backend twice.
DiffTrain build for commit https://github.com/facebook/react/commit/67a05d03e38b9837e27c9fe0a673557e63ff03c5.
Reviewed By: javache
Differential Revision: D45815160
Pulled By: hoxyq
fbshipit-source-id: 99f3c45009b07a0fb89f0674ccfb24f170cdb29d
Summary:
For these values we're not using dynamic values. We can statically
compile in the values we're running.
DiffTrain build for commit https://github.com/facebook/react/commit/df12d7eac40c87bd5fdde0aa5a739bce9e7dce27.
Reviewed By: tyao1
Differential Revision: D45751304
Pulled By: kassens
fbshipit-source-id: d00e441ab75bf8fe038bb0e80eeb392421344657
Summary:
When I was renaming the next channel to canary, I updated the
`publish_preleases` workflow correctly, but I skipped over
`publish_preleases_nightly`. Oops.
DiffTrain build for commit https://github.com/facebook/react/commit/7cd98ef2bcbc10f164f778bade86a4daeb821011.
Reviewed By: mofeiZ
Differential Revision: D45720403
fbshipit-source-id: 13ab5d0d0af6cc899944507249b39b03adbcb994
Summary:
The idea is that the default `yarn test` command should be the one that
includes the most bleeding edge features, because during development you
probably want as many features enabled as possible.
That used to be `www-modern` but nowadays it's `experimental` because
we've landed a bunch of async actions stuff in experimental but it isn't
yet being tested at Meta.
So this switches the default to `experimental`.
DiffTrain build for commit https://github.com/facebook/react/commit/b5810163e913e8c95a7a0a6dee039bc102e3c987.
Reviewed By: mofeiZ
Differential Revision: D45719891
fbshipit-source-id: 7c820b8b546f1c90bb3d77993befde86e42d399b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/37349
X-link: https://github.com/facebook/yoga/pull/1288
Fixes https://github.com/facebook/yoga/issues/1283
New versions of CMake add "policies" which control how the build system acts wrt breaking changes. By default, CMake will emulate the behavior of the version specified in `cmake_minimum_required`.
Setting a policy to true (to opt into new behavior where `cmake_minimum_required` is lower than the current version) seems actually just error out on the old versions.
Googling around, apparently the way I should be doing this is to specify `<policy_max>` as part of `cmake_minimum_required `. https://gitlab.kitware.com/cmake/cmake/-/issues/20392
This should I think use new policies introduced up to 3.26 (what we test on right now), while letting 3.13 be the minimum.
Reviewed By: cortinico
Differential Revision: D45724864
fbshipit-source-id: 120cc2015a043605e7c07ef0459667643a4284b7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/37441
Changelog: [Internal]
i just noticed that `[_delegate createContextContainer]` can be null because it returns `shared_ptr`, we should protect against that!
Reviewed By: javache
Differential Revision: D45805196
fbshipit-source-id: 645815812da1718e1025c7e6b2763e698d86b59a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/37442
Changelog: [Internal]
this better describes what's going on and is more standard obj-c
Reviewed By: javache
Differential Revision: D45805034
fbshipit-source-id: d8e5938c856f356ce96a3f6d393eaddbb02aa555
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/37396
Pull Request resolved: https://github.com/facebook/react-native/pull/37368
## Changes
This diff hooks up global.nativeModuleProxy to the TurboModule interop layer.
Now, when you call NativeModules.Foo, the TurboModule system will create the Foo legacy module, and return it to JavaScript.
## Example
global.nativeModuleProxy.Foo:
- ObjC++: Use RCTTurboModuleManager to create the ObjC legacy module for Foo
- C++: Use the ObjC legacy modules to create and return a ObjCInteropTurboModule object to JavaScript.
Changelog: [Internal]
Reviewed By: cipolleschi
Differential Revision: D45781152
fbshipit-source-id: 9059cd0de294aa17dcbf120322d7e86e7c7a83ed
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/37395
Pull Request resolved: https://github.com/facebook/react-native/pull/37364
When the TurboModule interop layer is enabled, it should create modules that conform to RCTBridgeModule (i.e: legacy and turbo modules).
When the TurboModule interop layer is disabled, it should only create modules that conform to RCTTurboModule (i.e: turbo modules).
Changelog: [Internal]
Reviewed By: cipolleschi
Differential Revision: D45781155
fbshipit-source-id: 2bf2c6cdbe0db99a57fce0d0c21c66aee3465e0d
Ramanpreet Nara
Mathias Stearn
Neil Dhar
Nicola Corti
Blake Friedman
Intl Scheduler
Riccardo Cipolleschi
Ana Margarida Silva
Sam Zhou
Pieter De Baets
Lorenzo Sciandra
Douglas Lowder
Christoph Purrer
Adam Cmiel
Samuel Susla
Antoine Doubovetzky
Kyaw Thura
shubham0142
tarunrajput
Siddarth Kumar
Philip Heinser
Phillip Pan
javache (Meta Employee)
hoxyq (Meta Employee)
kassens (Meta Employee)
acdlite
Nick Gerleman
