Summary:
When downloading Hermes from source on Circle CI, the process will fail because Circle CI macOS machines do not have wget installed.
Since curl can serve the same purpose and it is already part of the installed software on macOS machines, we can use curl in place of wget.
This change ensures Hermes can be built from source on Circle CI jobs.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D35294868
fbshipit-source-id: bb099b603ef64205d45b833882852b2f4d6060ca
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/33535
Hack to support Kotlin functions in Buck compilation: adds Kotlin stdlib as a dependency to make sure upstream targets include Kotlin jvm internal classes.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D35284430
fbshipit-source-id: 0d29ad30386514c8df5376d0a6809d3105f0cd0f
Summary:
This are the two package upgrade required for this package to run with ESLint 8
## Changelog
[JavaScript] [Changed] `react-native-community/eslint-config` to work with ESLInt 8
Pull Request resolved: https://github.com/facebook/react-native/pull/33448
Test Plan: Try the package with ESLint 8
Reviewed By: yungsters
Differential Revision: D35012075
Pulled By: GijsWeterings
fbshipit-source-id: 7de68c770fb31fe8ec06c805afea9b5f3a7a7294
Summary:
Restore `nightly` jobs to green by removing `hermesc` from `react-native` package.
As a result, when building Hermes from source on developer's machines, the Hermes compiler will need to be built as well.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D35289425
fbshipit-source-id: 2a058f714d670fbb4d0486e7280cab7dd923fc63
Summary:
As users can toggle `enableSeparateBuildPerCPUArchitecture` to create a split APK, once that is off, the `-PreactNativeArchitecture` is not correctly considered when building the local module.
This will make sure that, if users have `enableSeparateBuildPerCPUArchitecture` set to `false`, their
app is building the local `app_modules` only for the requested architectures.
Practically, users invoking with `--active-arch-only` might experience a build failure if they have a fully clean environment (would be forced to do a full build before using `--active-arch-only`). This addresses this scenario.
Changelog:
[Android] [Fixed] - Template: Specify abiFilters if enableSeparateBuildPerCPUArchitecture is not set.
Reviewed By: ShikaSD
Differential Revision: D35250700
fbshipit-source-id: 4e555888636cf182495fab2b4a562d93a70b9e66
Summary:
The getAll() method of the [FormData](https://developer.mozilla.org/en-US/docs/Web/API/FormData) interface returns all the values associated with a given key from within a FormData object.
## Changelog
[General] [Added] - Add getAll function to FormData class for getting all parts containing that key. This is also available in web API.
Pull Request resolved: https://github.com/facebook/react-native/pull/32444
Test Plan: New test added in FormData-test.js
Reviewed By: lunaleaps
Differential Revision: D31798633
Pulled By: cortinico
fbshipit-source-id: ef29bb54e930532a671adbe707be8d1a64ff0d82
Summary:
Upgrade React Native's direct dependencies on Metro packages from 0.69.1 to 0.70.0.
Metro release notes: https://github.com/facebook/metro/releases/tag/v0.70.0
Changelog:
[Internal]
Reviewed By: motiz88
Differential Revision: D35258405
fbshipit-source-id: f46f28c177f9f7fdaf2e680ab5c6c350cee4308d
Summary:
This adds an unnecessary dependency between two NPM package which can be avoided. See https://github.com/reactwg/react-native-releases/discussions/17#discussioncomment-2452813
for context.
Changelog:
[Internal] [Changed] - react-native-gradle-plugin should not depend on react-native-codegen NPM package
Reviewed By: dmitryrykun
Differential Revision: D35279729
fbshipit-source-id: f18f79809f115f28203ac0a843fafead63528904
Summary:
Aligns naming with `JWritableMapBuffer` and other fbjni classes to indicate that it is a JNI binding.
Changelog: [Internal] - Rename C++ part of ReadableMapBuffer to JReadableMapBuffer
Reviewed By: mdvacca
Differential Revision: D35219323
fbshipit-source-id: a7eb644a700a35dc94fa18e4fb3cc68f2cfa3e99
Summary:
Updates `ReadableMapBuffer` to conform to `MapBuffer` interface, to allow interchangeable use of `Readable/WritableMapBuffer` in the code.
Notable changes:
- MapBuffer.Entry getters are now represented as Kotlin properties and appended `Value` suffix (e.g. `entry.getInt()` becomes `entry.getIntValue()` in Java, or `entry.intValue` in Kotlin)
- `ByteBuffer` is imported in constructor instead of on demand. This method doesn't copy the data as the bytes are read directly from native heap, and benchmarking a 500-byte `MapBuffer` shows no difference in import speed.
- Internal logic of `ReadableMapBuffer` uses `UShort` kotlin type for key retrieval, for more correct representation of values.
- Explicit exception throws are replaced with `require` and `check` methods for `IllegalArgumentException` and `IllegalStateException` (default FB conversion).
The change also updates `ReadableMapBuffer` usages to `MapBuffer` interface where possible (virtually everywhere except JNI methods).
Changelog: [Android][Changed] - Adopt `MapBuffer` interface for `ReadableMapBuffer`
Reviewed By: mdvacca
Differential Revision: D35218633
fbshipit-source-id: 515dd974c27b2978ade325b2e1750ab8f068a20a
Summary:
Creates a `WritableMapBuffer` abstraction to pass data from JVM to C++, similarly to `ReadableMapBuffer`. This part also defines a Kotlin interface for both `Readable/WritableMapBuffer` to allow to use them interchangeably on Java side.
`WritableMapBuffer` is using Android's `SparseArray` which has almost identical structure to `MapBuffer`, with `log(N)` random access and instant sequential access.
To avoid paying the cost of JNI transfer, the data is only transferred when requested by native `JWritableMapBuffer::getMapBuffer`. `WritableMapBuffer` also owns it data, meaning it cannot be "consumed" as `WritableNativeMap`, with C++ usually receiving copy of the data on conversion. This allows to use `WritableMapBuffer` as JVM-only implementation of `MapBuffer` interface as well, e.g. for testing (although Robolectric will still be required due to `SparseArray` used as storage)
Changelog: [Android][Added] - MapBuffer implementation for JVM -> C++ communication
Reviewed By: mdvacca
Differential Revision: D35014011
fbshipit-source-id: 8430212bf6152b966cde8e6f483b4f2dab369e4e
Summary: Changelog: [Internal] Add another example for testing out the pointer events spec
Reviewed By: vincentriemer
Differential Revision: D35116565
fbshipit-source-id: 5f0cfeb871ae55071549c2289782401807f55515
Summary:
While it would be better to be able to do all of the ownership metadata at the Buck macro level, that proved to be more work than expected.
This diff adds the corresponding pfh label to all targets in `xplat/js/react-native-github` that have a Supermodule label. Once the migration is complete the Supermodules labels will be able to be removed.
Reviewed By: cortinico
Differential Revision: D35221544
fbshipit-source-id: d87d5e266dfb5e6ee087251dc34dff5db299bbaf
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/33518
Changelog: [Internal]
When building with buck2, `setup_env_vars.sh` cannot be found. exporting setup_env_vars.sh and adding it as a dep to `write_to_json` fixes it.
Reviewed By: d16r
Differential Revision: D35188154
fbshipit-source-id: e1e1be4c83a57e443a181efaf1af3e6c8e6452f9
Summary:
These `constexpr` template variables make it really easy to test for bridging conversion to/from the specified types. The unit tests for this actually uncovered a bug with incompatible casts from lvalue references that was fixed in this diff as well.
Changelog:
Internal
Reviewed By: christophpurrer
Differential Revision: D35105398
fbshipit-source-id: 6e5f16e44ba99b296284970bf32c1f2f47201391
Summary:
I've noticed that some builds are sporadically failing as `configureCMake*` is runnign before
`preBuild`. When this happens, some 3rd party library folder won't exist yet and the build will
essentially fail. This is introducing flakyiness that this commit is essentially reducing
Changelog:
[Internal] [Changed] - Reintroduce missing dependency between configureCMakeDebug and preBuild
Reviewed By: ShikaSD
Differential Revision: D35213932
fbshipit-source-id: bfb4173843349ca4c1699d584bf0c915ab7b35cf
Summary:
Changelog: [iOS][Internal] Add api to disable New validation reporting
Previously `RCTNewArchitectureValidationSetEnabled` was not set to false once it was set to true when a use is in app-wide Bridgeless mode.
This resulted it being in an incorrect state if a user:
1) Opens RN while in app-wide Bridgeless enabled
2) Logout
3) Re-login as another user without killing the app.
The fix is to set `RCTNewArchitectureValidationSetEnabled(RCTNotAllowedValidationDisabled)` in FBReactModule initialization.
Reviewed By: RSNara
Differential Revision: D35233335
fbshipit-source-id: 82a2c2ed030df5d68267a40b14322e652eb29e96
Summary:
Changelog: [iOS][Internal] Refactor: Migrate Logbox surface initialization to Fabric when available, in Bridge and Bridgeless modes
# Why
This diff main purpose is to add `RCTErrorNewArchitectureValidation(RCTNotAllowedInAppWideFabric)` in `RCTSurface`, to ensure Paper surfaces are never created in FBiOS.
# The Situation
Before this diff, in Bridged Fabric, `[RCTLogbox show]` initializes a Paper `RCTSurface`, [using `[RCTLogBoxView initWithWindow]`](https://github.com/facebook/react-native/blob/main/React/CoreModules/RCTLogBoxView.mm#L46))
In this diff, in Bridged and Bridgeless Fabric, `[RCTLogbox show]` initializes a Fabric `RCTFabricSurface`.
Before this diff, in Bridgeless Fabric, RCTLogBox posts a "CreateLogBoxSurface" notification to RCTInstance.
In this diff, the notification hack is replaced by the same `RCTFabricSurface` initialization above.
Behavior is the same.
Reviewed By: RSNara
Differential Revision: D35177311
fbshipit-source-id: 6de418af8a01f914c9a806bb8d74915015f9087a
Summary:
Changelog: [iOS][Internal] Remove RCTNotAllowedInBridgeless validation for RCTRegisterModule
In the TurboModule system, `RCTRegisterModule` gets called for all `RCTBridgeModules` that calls `RCT_EXPORT_MODULE()` and it works fine in Bridgeless mode.
Reviewed By: RSNara
Differential Revision: D35203039
fbshipit-source-id: 8ae2be4487fe21653a7f1628fa92606a7d36d467
Summary:
In short, if an RCTEventDispatcher observer sends an event on the same thread that the observer was initially on, there will be a deadlock due to `sendEvent` already having the lock active on the `_observers` NSHashTable. An example where this occurred was when we had react-native-gesture-handler trigger an animated event, which then triggered an event on the underlying component being animated as a result of it being an observer on the animation event. Since this all occurred on the main thread, we ended up with a deadlock and the app froze.
To prevent this scenario, I used a `NSRecursiveLock` for _observersLock to be able to dispatch events on the same thread from observers.
joebernard
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://github.com/facebook/react-native/wiki/Changelog
-->
[iOS] [Fix] - Prevent deadlock when dispatching events from observers on the same thread.
Pull Request resolved: https://github.com/facebook/react-native/pull/33490
Test Plan:
Not sure if there are any tests present for sending events with RCTEventDispatcher already in place, but In regular app usage this solution has proved to be a viable and stable option so far and has prevented the deadlock from occurring.
This would still be thread-safe since we are now allowing the event to be sent through observers on the same thread the initial event was dispatched on. The only issue I could see here is the behavior of sending an event could be changed.
Reviewed By: RSNara
Differential Revision: D35118752
Pulled By: charlesbdudley
fbshipit-source-id: 7e93a8d49841e001b235a437ccca1e072dcc7ab1
Summary:
Changelog: [Fabric][iOS] Allow CKComponents to embed Fabric surfaces too.
Previously RCTSurfaceHostingComponent, a CKComponent, could only initialize the legacy RCTSurface. Now it can initialize RCTFabricSurface too, when a RCTSurfacePresenter is passed in.
Reviewed By: RSNara
Differential Revision: D35163595
fbshipit-source-id: e11a9334b0282e0728a38cc1c96de48a694e9e3d
Summary:
Changelog: [iOS][Internal] Refactor: Make ComponentKit hosting ReactNative use RCTSurfaceProtocol instead of Paper's RCTSurface
Replace RCTSurface with id<RCTSurfaceProtocol>, because both RCTFabricSurface and RCTSurface conforms to RCTSurfaceProtocol.
Reviewed By: RSNara
Differential Revision: D35163498
fbshipit-source-id: ba54c9bf5949313cd501bd185975fe96d4770961
Summary:
Changelog:
Before diff, we always hit assert the `'self.component' must be called on the main thread` assertion whenever we open a surface with a RCTSurfaceHostingComponent (React Native surface inside a CKComponent).
Reviewed By: RSNara
Differential Revision: D35152263
fbshipit-source-id: 1b06ca9d2ae7ca211120b71504e2eeaabaaf3bfd
Summary:
Changelog: [iOS][Internal] Rename RCTNotAllowedInFabric to RCTNotAllowedInAppWideFabric
Clarify that methods marked with `RCTNotAllowedInAppWideFabric` are only NOT available when Fabric is app-wide (which is necessary for app-wide Bridgeless mode). These methods may still be called in apps with legacy pre-Fabric surfaces.
Reviewed By: RSNara
Differential Revision: D35194789
fbshipit-source-id: e16fa54d22ea67be995e93f6ff60567a117398be
Summary:
Adding more context for event dispatching process in systrace.
Changelog: [Internal]
Reviewed By: philIip
Differential Revision: D35208257
fbshipit-source-id: 4a70e15a0074d4a53a895066e6fa1e60a6ebda0d
Summary:
The Array appended to FormData must be transmitted in the form of a string.
However, it is treated as a file object and transmitted, because `typeof Array` is `'object'` too
In network
```js
form.append('array_name', ['a', 'b', 'c'])
// Browser
// Content-Disposition: form-data; name='array_name';
// a,b,c
// ReactNative
// Content-Disposition: form-data; name='array_name';
//
```
## Changelog
[General] [Fixed] - The Array appended to FormData is transmitted as a string
Pull Request resolved: https://github.com/facebook/react-native/pull/32815
Test Plan: Added test case
Reviewed By: lunaleaps
Differential Revision: D33369594
Pulled By: charlesbdudley
fbshipit-source-id: 0b5219a2c9f73cf16665dc417cceb4481428ad4e
Summary:
As per commit: 4f3b174120 which states that "React Native requires that the RootView id be managed entirely by React Native, and will crash in addRootView/startSurface if the native View id isn't set to NO_ID."
This behaviour can not be guaranteed in **hybrid** apps that have a native android layer over which ReactRootViews are added and the native views need to have ids on them in order to work. **The control of views can jump back and forth between native android and react-native (fabric). As the ReactRootView is added to ViewGroups (or layouts) in Android Fragments and Activities, they contain ids on their views which might get passed down to the reactRootView by features like DataBinding**
Hence this can cause unnecessary crashes at runtime for hybrid apps even when they are not changing the id of the reactRootView object they are adding to their ViewGroups.
Our app is a hybrid app that uses both native android and react-native on different screens and on one such screen that has a Fragment adding a ReactRootView to its FrameLayout to render native android views to render in ReactNative, this crash occurs on pressing the back button as well as on unlocking the screen while staying on the same screen.
The app was running fine on more than a 100 million devices on React Native 0.63.4 but after updating to 0.67.2, that features this commit, it crashes on the very first device it was tested on.
Refer to the issue: https://github.com/facebook/react-native/issues/33121 for more information on the crash
The fragment in which this issues arises is like this:
```binding.frameLayout.addView(getReactRootView())```
where getReactRootView() is like this:
```
private var mReactRootView: ReactRootView? = null
private var mReactInstanceManager: ReactInstanceManager? = null
mReactRootView = ReactRootView(context)
if (activity != null) {
val application = activity?.application
if (application is MainApplication) {
mReactInstanceManager = application.reactInstanceManager
}
}
fun getReactRootView():View?{
return mReactRootView
}
```
So converting this to a soft exception such that pure react-native devs can still see the error while hybrid apps continue to run without crashes.
### Snippet of the change:
```
if (getId() != View.NO_ID) {
ReactSoftExceptionLogger.logSoftException(
TAG,
new IllegalViewOperationException(
"Trying to attach a ReactRootView with an explicit id already set to ["
+ getId()
+ "]. React Native uses the id field to track react tags and will overwrite this"
+ " field. If that is fine, explicitly overwrite the id field to View.NO_ID."));
}
```
## Changelog
[GENERAL] [ADDED] - A ReactSoftException log instead of a direct exception being thrown:
```
if (getId() != View.NO_ID) {
ReactSoftExceptionLogger.logSoftException(
TAG,
new IllegalViewOperationException(
"Trying to attach a ReactRootView with an explicit id already set to ["
+ getId()
+ "]. React Native uses the id field to track react tags and will overwrite this"
+ " field. If that is fine, explicitly overwrite the id field to View.NO_ID."));
}
```
[GENERAL] [REMOVED]- Directly throwing an exception even when the code is not responsible for this issue:
```
if (getId() != View.NO_ID) {
throw new IllegalViewOperationException(
"Trying to attach a ReactRootView with an explicit id already set to ["
+ getId()
+ "]. React Native uses the id field to track react tags and will overwrite this"
+ " field. If that is fine, explicitly overwrite the id field to View.NO_ID.");
}
```
Pull Request resolved: https://github.com/facebook/react-native/pull/33133
Test Plan:
This crash is hard to reproduce but when it occurs, this is the only way to fix it.
If any app used to crash with this exact error, it will no longer crash but show an error log in Logcat for developers to be informed about the issue.
Reviewed By: ShikaSD
Differential Revision: D34304212
Pulled By: cortinico
fbshipit-source-id: f0eaeef2e905a6e0587df088b43cc49cabda397a
Summary:
Add cached yarn deps
Seeing the message below during development, packages are outdated
```
=============
WARNING: You are currently running a version of TypeScript which is not officially supported by typescript-eslint/typescript-estree.
You may find that it works just fine, or you may not.
SUPPORTED TYPESCRIPT VERSIONS: >=3.3.1 <4.1.0
YOUR TYPESCRIPT VERSION: 4.5.4
Please only submit bug reports when using the officially supported version.
=============
```
Update packages below to "5.8.0" should fix this
- typescript-eslint/eslint-plugin
- typescript-eslint/parser
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://github.com/facebook/react-native/wiki/Changelog
-->
[General][Changed] - Bump dependencies version for eslint-plugin
Pull Request resolved: https://github.com/facebook/react-native/pull/32800
Test Plan: `yarn lint` with no error
Reviewed By: cortinico, yungsters
Differential Revision: D33331050
Pulled By: charlesbdudley
fbshipit-source-id: 27bf9b9b0536545ebfe4614ed210255df65aa2cd
Summary:
This PR fixes RTTI (run-time type information) for ShadowNodeWrapper and ShadowNodeListWrapper classes, i.e., calls to dynamic_cast and dynamic_pointer_cast that are called via JSI's getHostObject calls.
The fix is simply to add a so-called "key function" in a form of virtual destructor. Key functions needs to be a virtual non-pure and non-inlined functions that points the compiler as to which library contains the vtable/type information for a given class (see https://itanium-cxx-abi.github.io/cxx-abi/abi.html#vague-vtable and https://developer.android.com/ndk/guides/common-problems#rttiexceptions_not_working_across_library_boundaries)
Without the "key function", calls to dynamic_cast for ShadowNodeWrapper instances won't work across library boundaries because the class will have separate definitions in each separate library, therefore objects created in one of those libraries won't be recognized as the same type by the other library. This has been a problem in reanimated and gesture-handler libraries where we call `object.getHostObject<ShadowNodeWrapper>(rt)` (this is a method from JSI) in order to access ShadowNode instance from a handle we have in JS. I think, this issue is going to be relevant to more libraries that cope with view instances. In this scenario, we have a separate library, say "libreanimated.so" that calls to `getHostObject` which is an inline function that calls `dynamic_cast` for the `ShadowNodeWrapper` class. On the other hand, the instances of `ShadowNodeWrapper` are created by the code from `libreact_render_uimanager.so`. Because of that `dynamic_cast` fails even though it is called on instance of `ShadowNodeWrapper` because the class has separate vtable/type info: one in `libreanimated.so` and one in `libreact_render_uimanager.so` (by "fails" I mean that it actually returns `nullptr`).
This problem has been documented here: https://developer.android.com/ndk/guides/common-problems#rttiexceptions_not_working_across_library_boundaries where the solution is for the class to have a so-called "key function". The key function makes it so that compiler sees that one of the implementation for a given class is missing and therefore can safely assume that a vtable/type info for a given class is embedded into some library we link to.
This change adds a virtual destructor that is declared in the header file but defined in file that gets compiled as a part of `libreact_render_uimanager`. As a result, the compiler only creates one vtable/type info and calls to dynamic_cast works as expected in all libraries for `ShadowNodeWrapper` and `ShadowNodeListWrapper` classes.
This issue would only surface on Android, because on iOS all libraries by default are bundled together via Pods, whereas on Android each library is loaded separately using dynamic loading.
## Changelog
[Fabric][Android specific] - Fix dynamic_cast (RTTI) for ShadowNodeWrapper and similar classes when accessed by third-party libraries.
Pull Request resolved: https://github.com/facebook/react-native/pull/33500
Test Plan:
1. In order to test this you need to add a library that'd include `<react/renderer/uimanager/primitives.h>` (i.e. use this branch of reanimated library: https://github.com/software-mansion/react-native-reanimated/tree/fabric)
2. After compiling the app inspect libreact_render_uimanager.so and libreanimated.so artifacts with `nm` tool
3. Notice that symbols like `vtable for facebook::react::ShadowNodeWrapper` and `typeinfo for facebook::react::ShadowNodeWrapper` are only present in the former and not in the latter library (before this change you'd see them both)
Reviewed By: ShikaSD
Differential Revision: D35143600
Pulled By: javache
fbshipit-source-id: 5fb25a02365b99a515edc81e5485a77017c56eb8
Summary:
If an RN app is embedded in a Mac Catalyst app that uses the UIWindowScene API to manage multiple windows, LogBox would fail to render because it didn't know which UIWindowScene to render to. This diff fixes that situation by ensuring that the LogBox window gets rendered in the key window's scene.
Changelog:
[iOS][Fixed] - Update iOS LogBox to render its UIWindow with the key window's UIWindowScene
Reviewed By: appden
Differential Revision: D35027831
fbshipit-source-id: e0df5865f95323b03d08d6b1fb3ec912aa9a9167
Summary:
In https://github.com/facebook/react-native/blob/main/scripts/update-ruby.sh#L61
```bash
bundle lock
```
is called which creates a Gemfile.lock in the rn root. This file should be in the git add files list along with the other files that get updated by that script.
## Changelog
[Internal] [Fixed] - Added Gemfile.lock to git add files when calling update-ruby.sh
Pull Request resolved: https://github.com/facebook/react-native/pull/33484
Test Plan: Call update-ruby.sh with or without this patch. Without this patch, the Gemfile.lock will not be staged, with this patch, the Gemfile.lock will be staged.
Reviewed By: GijsWeterings
Differential Revision: D35118250
Pulled By: cortinico
fbshipit-source-id: 80f2c7fad6fbc3f09697988dcc20f7ac94a21473
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/33499
This DIFF turns on the `FB_SONARKIT_ENABLED` flag when installing Flipper ina RN app. The flag is enabled only in Debug config, given that Flipper is installed only in this configuration.
This PR also fixes this issue: https://github.com/facebook/react-native/issues/33497
This PR is required because release 0.67 has the Flag in the app, while release 0.68 moved it in the React-Core pod.
We can't enable the flag at the `React-Core.podspec` level because we should not make assumptions on whether users want flipper or not.
## Changelog
[iOS][Changed] - Enable SonarKit in React-Core when the configuration is `'Debug'`
Reviewed By: cortinico
Differential Revision: D35141506
fbshipit-source-id: 171b7fa8ea7727c633ef963408e86b332c32e9fa
Summary:
I noticed the `AppState.removeEventListener` was in fact calling `addListener` instead of `removeListener` when type is blur or focus.
I know this method is deprecated but it can't hurt to fix it.
## Changelog
[General] [Fixed] - AppState.removeEventListener correctly removes listener for blur and focus events
Pull Request resolved: https://github.com/facebook/react-native/pull/33491
Test Plan: I've thought about adding a unit test, but it isn't that easy since AppState is mocked and the method is deprecated so I don't think it is worth investing too much for it.
Reviewed By: cortinico
Differential Revision: D35139808
Pulled By: GijsWeterings
fbshipit-source-id: 9d8ba157db3a62ea53759e1246f483182faf12f1
Summary:
Undoing the recent change that enabled Hermes to be built from source by default.
Building Hermes from source now requires the use of the BUILD_HERMES_SOURCE envvar, again.
To be re-enabled shortly.
Pull Request resolved: https://github.com/facebook/react-native/pull/33478
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D35100459
fbshipit-source-id: ec83fcdf2432c689b0c02f86fbabcc8625975d51
Héctor Ramos
Marshall Roch
Andrei Shikov
Joe Frambach
William Candillon
Nicola Corti
matinzd
Rob Hogan
Luna Wei
Chris Olszewski
Wei Han
Scott Kyle
Paige Sun
Imran Shitta-Bey
fabriziobertoglio1987
Lulu Wu
Xin Chen
CodemodService Bot
bang9
Kunal Farmah
Mike
Krzysztof Magiera
Vincent Riemer
Danilo Bürger
Riccardo Cipolleschi
AntoineDoubovetzky
Rick Hanlon