Summary:
When using prebuilts the USE_FRAMEWORKS setting is not really relevant for the React Native code, since there will not be any source code to build frameworks for - and because we already have a framework for the code in React.XCFramework.
This commit adds a new command to the React Native podspecs like we did with the ReactNativeDependencies framework. The method is called `add_rncore_dependency` and it does nothing when building from source - but when linking with the React.XCFramework it explicitly adds linking with the framework.
In addition there are a few places in the ruby code where we check for the USE_FRAMEWORK value and changes some settings - where needed this commit will add a separate check to ensure we're building from source when making these changes.
bypass-github-export-checks
## Changelog:
[IOS] [ADDED] - Added support for using USE_FRAMEWORKS with prebuilt React Native Core
Pull Request resolved: https://github.com/facebook/react-native/pull/52489
Test Plan:
RNTester:
- Builds without USE_FRAMEWORKS as before with/without prebuilt
- Builds with USE_FRAMEWORKS=dynamic as before with source - and now also with prebuilt code.
- Same goes for the static variant.
Reviewed By: mdvacca
Differential Revision: D78012332
Pulled By: cipolleschi
fbshipit-source-id: ea942738ae52b9dceae48fb78a5026f04b7545b8
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52252
Instead of declaring two different sets of Pods for prebuilt and build from source, this commit now keeps the pod structure the same for both modes so that consuming libraries can expect to have the same pods and header files available - without this, libraries would have to be updated to take advantage of the prebuilds.
This PR does:
- Added React-Core-prebuilt as a pod in React-Core if prebuilt is enabled
- Simplified react_native_pods to keep pods structure and add React-Core-prebuilt pod if prebuilts are enabled
- Added function for selecting source sets based on prebuilt/build from source
To be able to function both in prebuilt and in regular build from source mode, all podspecs are now using the switch function podspec_sources so that they only include header files if we are in prebuild mode.
Also added React-Core-prebuilt as dependency on React-Core if we are in prebuilt mode so that we install the React.XCFramework.
## Changelog:
[IOS] [FIXED] - Added backwards compatible use of prebuild through cocoapods
Pull Request resolved: https://github.com/facebook/react-native/pull/52223
Test Plan:
Tested in RN-Tester both with and without prebuild.
Rollback Plan:
Reviewed By: cortinico
Differential Revision: D77296047
Pulled By: cipolleschi
fbshipit-source-id: f3eb4d56b2a78bfc8e10ad852746be1ceaf828b2
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50958
In rn-tester package there are many react-native deep imports which will be deprecated in the future. It is a starter for migrating rn-tester to using root imports instead. Only deep imports that are already root exported are changed. This diff avoids using `CodegenTypes` as it causes build errors and will be resolved in next stages.
Besides import changes, `PointerEvent` type is now also exported from the root.
Changelog:
[Internal]
Reviewed By: huntie
Differential Revision: D73656526
fbshipit-source-id: 5814a3d9c6a04b1236581dbbe291cd109e2c71c0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49968
Updates all the core podspec to use the new `ReactNativeDependencies` podspec
## Changelog:
[INTERNAL] - Updates Modules in core to use the new dependencies.
Test Plan:
✅ Run Rn-Tester and verify that it works as expected both building deps from source and using prebuilt tarballs
✅ Add third-party library (react-native-reanimated) and perform the same tests to verify that it works with the changed podspec and utilities
Reviewed By: cortinico
Differential Revision: D71032639
Pulled By: cipolleschi
fbshipit-source-id: e53179a8c1b47ee2b945f5cb5dfaf3f6f2755af2
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49601
Changelog: [internal]
This creates a new module in React Native to define some of the types related to `HostInstance` that are currently defined in `ReactNativeTypes` (synced from the React repo).
We want to remove the types from `ReactNativeTypes` so this is a necessary initial step.
Reviewed By: huntie
Differential Revision: D69996010
fbshipit-source-id: 21cfed4c222e22332936e56aca895fe578809792
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48054
Web debugging should be fully removed as of recent, so lets remove some of the gunk that was powering it, and checks for that environment.
I did some string searches for the following:
* isAsyncDebugging
* debugRemotely
* isDebuggingRemotely
* isRemoteDebuggingAvailable
* WebSocketExecutor
* JavaJSExecutor
* ProxyJavaScriptExecutor
* RELOAD_APP_EXTRA_JS_PROXY
* getJSBundleURLForRemoteDebugging
* onReloadWithJSDebugger
* setRemoteJSDebugEnabled
* WebsocketJavaScriptExecutor
* createRemoteDebuggerBundleLoader
1. `expo-modules-core` exposes its own `isAsyncDebugging` by checking for `nativeCallSyncHook`, but does not depend on `DebugEnvironment`.
2. `expo-dev-menu` does read `isDebuggingRemotely` from `DevSettings`.
3. Realm does a check in Native using `objc_lookUpClass("RCTWebSocketExecutor")` but will gracefully handle `nil` if it does not exist
4. Some more usages (e.g. `onReloadWithJSDebugger`) in vendored packages of `expo-dev-launcher` for RN 0.74
I created an issue for Expo mentioning both here: https://github.com/expo/expo/issues/33371
Changelog:
[General][Breaking] - Remove some web debugging remnants
Reviewed By: huntie
Differential Revision: D66553934
fbshipit-source-id: deec382b1c8bda393fddb8682aa91b26afd9fbe3
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45374
This change factors out the language standard in a separate constant so we can easily control it from a single place.
There are only 2 exception to this:
1. hermes-engine: the podspec is used in CI and it has no access to the rct_cxx_language_standard variable
2. Yoga: it can be used as a separate pod, outside of React Native, so it makes sense to leave it alone.
This change also fixes a problem where, in some setup, the language was set to C++14
## Changelog
[Internal] - Refactor Cxx language standard in a single constant
Reviewed By: dmytrorykun, blakef
Differential Revision: D59629061
fbshipit-source-id: 41eac64e47c14e239d8ee78bd88ea30af244d695
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42153
This non functional change unifies Folly version and compiler flag in a single function, so that it would be easier to update it in the future.
## Changelog:
[Internal] - Unify folly version and compiler flags
Reviewed By: cortinico
Differential Revision: D52564771
fbshipit-source-id: 9b4b50560ddee05ce50465b6854666572148cb25
Summary:
Bump folly version to 2024.01.01.00. Actually we need a version newer than v2023.08.14.00 with the https://github.com/facebook/folly/commit/c52d4490bf1e0cf117a71342b427984f9ffc316e fix. That will fix build error on Android:
```
In file included from /Users/kudo/expo/expo/node_modules/react-native-reanimated/android/src/main/cpp/NativeProxy.cpp:3:
In file included from /Users/kudo/.gradle/caches/transforms-3/dd158a7d05d059a173ae31ca6d78ac49/transformed/jetified-react-android-0.74.0-nightly-20240103-0e533f308-SNAPSHOT-debug/prefab/modules/jsi/include/jsi/JSIDynamic.h:10:
In file included from /Users/kudo/.gradle/caches/transforms-3/dd158a7d05d059a173ae31ca6d78ac49/transformed/jetified-react-android-0.74.0-nightly-20240103-0e533f308-SNAPSHOT-debug/prefab/modules/folly_runtime/include/folly/dynamic.h:1310:
In file included from /Users/kudo/.gradle/caches/transforms-3/dd158a7d05d059a173ae31ca6d78ac49/transformed/jetified-react-android-0.74.0-nightly-20240103-0e533f308-SNAPSHOT-debug/prefab/modules/folly_runtime/include/folly/dynamic-inl.h:22:
In file included from /Users/kudo/.gradle/caches/transforms-3/dd158a7d05d059a173ae31ca6d78ac49/transformed/jetified-react-android-0.74.0-nightly-20240103-0e533f308-SNAPSHOT-debug/prefab/modules/folly_runtime/include/folly/Conv.h:124:
In file included from /Users/kudo/.gradle/caches/transforms-3/dd158a7d05d059a173ae31ca6d78ac49/transformed/jetified-react-android-0.74.0-nightly-20240103-0e533f308-SNAPSHOT-debug/prefab/modules/folly_runtime/include/folly/Demangle.h:19:
/Users/kudo/.gradle/caches/transforms-3/dd158a7d05d059a173ae31ca6d78ac49/transformed/jetified-react-android-0.74.0-nightly-20240103-0e533f308-SNAPSHOT-debug/prefab/modules/folly_runtime/include/folly/FBString.h:1721:19: error: no member named 'strong_ordering' in namespace 'std'
return std::strong_ordering::equal;
~~~~~^
/Users/kudo/.gradle/caches/transforms-3/dd158a7d05d059a173ae31ca6d78ac49/transformed/jetified-react-android-0.74.0-nightly-20240103-0e533f308-SNAPSHOT-debug/prefab/modules/folly_runtime/include/folly/FBString.h:1723:19: error: no member named 'strong_ordering' in namespace 'std'
return std::strong_ordering::less;
~~~~~^
/Users/kudo/.gradle/caches/transforms-3/dd158a7d05d059a173ae31ca6d78ac49/transformed/jetified-react-android-0.74.0-nightly-20240103-0e533f308-SNAPSHOT-debug/prefab/modules/folly_runtime/include/folly/FBString.h:1725:19: error: no member named 'strong_ordering' in namespace 'std'
return std::strong_ordering::greater;
~~~~~^
3 errors generated.
```
## Changelog:
[GENERAL] [CHANGED] - Bump folly version to 2024.01.01.00
Pull Request resolved: https://github.com/facebook/react-native/pull/42145
Test Plan: ci passed
Reviewed By: cortinico, cipolleschi
Differential Revision: D52546945
Pulled By: NickGerleman
fbshipit-source-id: 64aacb1d310062dddf987c7b95f10a477e293693
Summary:
The goal for this PR is to further remove references for `[UIScreen mainScreen]` and migrate them to use trait collections. This helps out of tree platforms like visionOS (where the `UIScreen` is not available).
bypass-github-export-checks
## Changelog:
[INTERNAL] [CHANGED] - use currentTraitCollection for FBSnapshotTestController.m
[IOS] [CHANGED] - use key window width to assign the correct width for RCTDevLoadingView
Pull Request resolved: https://github.com/facebook/react-native/pull/41388
Test Plan:
– Check if tests passes
- Check if `RCTDevLoadingView` shows up correctly.
Screenshot:
Reviewed By: javache
Differential Revision: D51156230
Pulled By: cipolleschi
fbshipit-source-id: bbe711e0281046a082fd1680b55e2d117915ad00
Summary:
This bumps folly, to absorb https://github.com/facebook/folly/commit/45fffa629d6bf7321391222d40613d75e8e067d7 which fixes warnings in XCode 15, and NDK 26 (treated as error bc we have better hygiene there). We then bump a little bit further to get past a new warning added, then fixed later.
Need to manually set `FOLLY_HAVE_GETTIME` on Apple because of the silliness described in https://github.com/facebook/folly/issues/1470#issuecomment-1746035194
There is not a combination of Folly, and Android libc++, that has fixes for warnings, but doesn't require the new libc++ in NDK 26. It is expected then that this commit will fail the build, but the next should succeed, and the two must be landed at the same time.
Changelog: [Internal]
Pull Request resolved: https://github.com/facebook/react-native/pull/39798
Reviewed By: fkgozali
Differential Revision: D49897681
Pulled By: NickGerleman
fbshipit-source-id: 52b97ed5b302abf9e27f38dc655207827852dcc3
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39454
1. Build with C++ 20 everywhere.
2. Update folly in OSS build to avoid a warning, and let us opt out of heavy bits required for supporting coroutines (we are still more than a year behind).
3. Update the folly podspec for the new version of folly
4. Update the many, many, copy/pasted header search paths for folly dependencies to be able to resolve fmt, now exposed to folly headers
4. Replaces a deprecated atomic usage with equivalent.
5. Fixes a deprecated implicit capturing `this` by value in lambda (same behavior, added a TODO because it seems sus)
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D49271685
fbshipit-source-id: 16610f7bcd1032d5796cc11f1cfa92a33d8c2593
Summary:
## Summary:
One of the most common diffs we have in React Native macOS is simply extending the `platforms` key Inside every pod spec to include macOS. React Native tvOS does the same to add tvOS. In the future, React Native may support visionOS, at which point we do the same thing again. Let's define a `min_supported_versions` hash that can be overridden at one place that is extensible to more platforms, instead of just specifying `min_ios_version_supported`.
Note: In doing this change, I have set it that `React-Hermes.podspec` doesn't build for macOS anymore. I think this is safe, since anyone using Hermes on macOS was probably using React Native macOS where we already have a diff to add macOS back?
## Changelog:
[IOS] [CHANGED] - Add min_supported_versions helper to cocoa pods scripts
Pull Request resolved: https://github.com/facebook/react-native/pull/39310
Test Plan: CI should pass.
Reviewed By: NickGerleman
Differential Revision: D49014109
Pulled By: dmytrorykun
fbshipit-source-id: d44fc7b750c70cc263a2c89502c022a0db9a4771
Summary:
This PR is another one made with the intent to reduce the number of diffs between React Native and React Native macOS.
In https://github.com/facebook/react-native/commit/f7219ec02d71d2f0f6c71af4d5c3d4850a898fd8#diff-d091f6636e07dc62dd7d892489355707c43923ac15056fd2eb59d9a297d576a6 , we introduced `kRCTPlatformName`, which had already been in React Native macOS for a while (since we ifdef to either "ios" or "macos" in a number of places). This change moves the string up to a common header (dropping the "k" prefix) so we can refactor other strings that currently have a hardcoded "platform=ios" inside them.
## Changelog:
[IOS] [CHANGED] - Add RCTPlatformName to RCTConstants.h
Pull Request resolved: https://github.com/facebook/react-native/pull/39141
Test Plan: CI should pass
Reviewed By: NickGerleman
Differential Revision: D48656197
Pulled By: lunaleaps
fbshipit-source-id: b9ff08e2591d7553a1a452795f36d4405ddaa5b1
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36795
This change bump the min iOS version for React Native to 13.4, to align with company guidelines.
## Changelog:
[iOS][Changed] - Moved the min iOS version to 13.4
Reviewed By: cortinico
Differential Revision: D44634663
fbshipit-source-id: 035e8fcbb395f7394f8253e3ec485ad9937531c2
Summary:
This is a small refactor designed to make future merges for React Native macOS easier. It was found while merging React Native 0.71 into React Native macOS.
In React Native macOS, we ifdef iOS out API's and replace them with macOS APIs, reusing as much code as possible. `CGContext` is a type that is available on both iOS and macOS, but `UIGraphicsImageRendererContext` is not. A simple refactor makes it easier to reuse this code in React Native macOS without affecting iOS :)
Resolves https://github.com/microsoft/react-native-macos/issues/1676
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
[IOS] [CHANGED] - Pull out CGContext early in UIImage+Diff
Pull Request resolved: https://github.com/facebook/react-native/pull/35940
Test Plan: Build should pass.
Reviewed By: matrush
Differential Revision: D42761424
Pulled By: javache
fbshipit-source-id: 5ce79a5e7c60484dd37d0b2c3f58ff0897d662df
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35038
React-jsi provides JSI to allow React Native to interface with JavaScriptCore.
The hermes-engine Pod provides a second copy of JSI, as Hermes is built and linked statically with JSI.
This second copy of JSI would lead to an [ODR Violation](https://en.cppreference.com/w/cpp/language/definition).
To resolve this, when Hermes is enabled:
- React-hermes and hermes-engine are installed.
- React-jsc is not installed.
- React-jsi continues to be installed.
- React-jsi will not build JSI.
- React-jsi will declare a dependency on hermes-engine.
The result is that the JSI dependency for React Native is satisfied by hermes-engine, and there is no duplicate JSI library in the project.
When Hermes is disabled:
- React-jsi and React-jsc are installed.
- React-hermes and hermes-engine are not installed.
- React-jsi will build JSI.
Changelog:
[iOS][Changed] Resolve JSI ODR violation, make hermes-engine the JSI provider when Hermes is enabled
Reviewed By: cipolleschi
Differential Revision: D40334913
fbshipit-source-id: 409407a193a35cbd21b0e8778537b3627e4c54a2
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35031
The React-jsi Pod was serving two purposes: building JSI, and configuring JavaScriptCore as the JS engine.
By splitting the React-jsi Pod into React-jsi and React-jsi, we can start working towards de-coupling the JSI dependency from any particular JS engine.
Pods that depended on React-jsi, now depend on React-jsi and React-jsc.
One exception to this is React-hermes, which is only installed when Hermes is enabled, and thus does not require JavaScriptCore.
Upcoming commits should take care of removing the React-jsc dependency when Hermes is enabled, but it is out of scope for this commit.
Changelog:
[iOS][Changed] - The JSC Runtime is now provided by the React-jsc Pod instead of React-jsi. Libraries that declared a dependency on React-jsi in order to specifically create a JSC runtime (`makeJSCRuntime()`) will need to add React-jsc to their dependencies.
Reviewed By: dmytrorykun
Differential Revision: D40442603
fbshipit-source-id: b9b21146b9deb401f80cfef76a87c9867754a953
Summary:
Bumping RTC-Folly version used to address CVE-2022-24440.
## 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][Security] - Bump RTC-Folly to 2021-07-22
Pull Request resolved: https://github.com/facebook/react-native/pull/33841
Reviewed By: Andjeliko, philIip
Differential Revision: D36425598
Pulled By: cortinico
fbshipit-source-id: d38c5f020dbecf794b10f12ed2da30e1825071af
Summary:
Apple suggested to this new API on iOS 10+.
> // Any new bitmap drawing code is encouraged to use UIGraphicsImageRenderer in lieu of this API.
WWDC18 Reference: https://developer.apple.com/videos/play/wwdc2018/219/
> Use UIGraphicsImageRenderer to create and draw to an image buffer
Supports Wide Color, unlike UIGraphicsBeginImageContext()
Combine with UIImageView for efficient offscreen rendering
Per https://nshipster.com/image-resizing/#performance-benchmarks, the new API runs even faster than the C version, probably due to more smart context reuses/management.
Changelog:
[iOS][Changed] - Adopt UIGraphicsImageRenderer API
Reviewed By: philIip
Differential Revision: D35699584
fbshipit-source-id: 7a1e2109d5e121fb396c1014f4ed0a892211b0cc
Summary:
as title
in practice, this doesn't make any difference, but this is to follow the apple recommendation and for us to have a more consistent codebase.
https://developer.apple.com/library/content/releasenotes/ObjectiveC/ModernizationObjC/AdoptingModernObjective-C/AdoptingModernObjective-C.html
>The NS_ENUM macro helps define both the name and type of the enumeration, in this case named UITableViewCellStyle of type NSInteger. The type for enumerations should be NSInteger.
>Like enumerations, the NS_OPTIONS macro defines both a name and a type. However, the type for options should usually be NSUInteger.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D32641990
fbshipit-source-id: 56e4cd44cdefe54f61c90844665a685ee2d6ffad
Summary:
As we're working on C++ code for RNTester to integrate Fabric, we should enable CLANGFORMAT for the files over there.
Changelog:
[Internal] [Changed] - Enable CLANGFORMAT on fbsource/xplat/js/react-native-github/packages
Reviewed By: ShikaSD
Differential Revision: D32493605
fbshipit-source-id: 7b5d63f6d2fae1a1aa1e782738953c8cd2cdbe4b
Summary:
Folly now depends on libc++abi. This solves linker error for RCT-Folly.podspec like this:
```
Undefined symbols for architecture arm64:
"___cxa_increment_exception_refcount", referenced from:
folly::exception_ptr_get_type(std::exception_ptr const&) in libRCT-Folly.a(Exception.o)
ld: symbol(s) not found for architecture arm64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
```
See https://github.com/react-native-community/releases/issues/251
Note: RNTester was not affected by this bug for some reason, so the only way to verify is via the new app generated via `npx react-native init`.
Changelog: [Fixed][iOS] Unbreak Folly linker error
Reviewed By: lunaleaps
Differential Revision: D30950944
fbshipit-source-id: 3eb146e23faa308a02363761d08849d6801e21ca
Summary:
1. [ios] upgrade folly to 2021.06.28.00 which aligned to android.
2. folly compile setting from c++14 -> c++17: _this folly requires c++17 for `std::unordered_map::insert_or_assign`._
3. boost 1.63.0 -> 1.76.0: _the old boost does not support c++17._
4. deprecating react-native-community/boost-for-react-native: _by cocoapods installer, we could download the official target._
## Changelog
[iOS] [Changed] - Upgrade folly to 2021.06.28.00 and boost to 1.76.0
Pull Request resolved: https://github.com/facebook/react-native/pull/31840
Test Plan: CI passed
Reviewed By: fkgozali
Differential Revision: D29668480
Pulled By: yungsters
fbshipit-source-id: 98eae9ca47f489dcea91974e6f5e9dcb4d66c40c
Summary:
This fixes an error where folly fails to build on Xcode 12.5, by bumping the various folly deps in RN to builds with a fix.
Next step is to commit this to 0.64 release branch
allow-large-files
Changelog: [iOS] Fix builds on Xcode 12.5
Reviewed By: fkgozali
Differential Revision: D28071808
fbshipit-source-id: 236b66bf8294db0c76ff25b11632c1bf89525921
Summary:
CocoaPods will display a "fatal: not a git repository" when these podspecs are consumed within Facebook's internal Mercurial repository due to the reliance on `git` to obtain the current commit hash.
In these cases, the podspec is being consumed locally and the commit hash is unnecessary.
The error is removed by avoiding the use of `git` if the current working directory is not a git repository (or any of the parent directories).
Changelog:
[Internal] [iOS] - Remove CocoaPods error within Facebook's repository
Reviewed By: fkgozali
Differential Revision: D27750974
fbshipit-source-id: 99159611c580baf5526f116948c5ff60e1c02e5c
Summary:
allow-large-files
Changelog: [iOS] Remove iOS10/tvOS10 suppport
Similar to D19265731 (https://github.com/facebook/react-native/commit/674b591809cd1275b5f1c4d203c2f0ec52303396) for iOS9.
I just ran this command:
`find . -type f -exec sed -i '' 's/{ :ios => "10.0" }/{ :ios => "11.0" }/' {} +`
and then updated pods
Reviewed By: fkgozali
Differential Revision: D25693227
fbshipit-source-id: 0073d57ecbb268c52d21962cef202316857bcbd2
Summary:
All NativeModules that use the bridge to require the eventDispatcher are now instead using the RCTModuleRegistry I introduced in D25412847 (https://github.com/facebook/react-native/commit/0ed81b28d3d786ea3b1cf0b932a008ef1f806ec4).
## What does this codemod do?
For all ObjC files that contain `synthesize bridge = _bridge`, migrate calls that access the React Native bridge from `self`, and use it to load the event dispatcher.
**Thoughts on Codemod Safety:** If we can access the bridge from self, then that means that if we synthesize the module registry, we can access the module registry from self. Therefore, this codemod is safe.
Changelog: [Internal]
Reviewed By: PeteTheHeat
Differential Revision: D25449795
fbshipit-source-id: 2f7235d14659e73d673ae08763dc2cccdde55a19
Summary:
This diff ended up being a bit more complicated than I anticipated, since the source files in `ReactInternal` were depending on `RCTEventDispatcher`. I made the following changes:
1. Make `RCTEventDispatcher` a `protocol`, keep it in `ReactInternal`.
2. Rename the `RCTEventDispatcher` NativeModule to `RCTEventDispatcherModule`, make it conform to the `RCTEventEmitter` `protocol`, and move it to `CoreModules`.
3. Where necessary, replace categories of `RCTEventDispatcher` with functions.
Changelog:
[iOS][Added] - Make RCTEventDispatcher TurboModule-comaptible
Reviewed By: fkgozali
Differential Revision: D18439488
fbshipit-source-id: b3da15c29459fddf884519f33b0c3b8c036b5539
Summary:
RNTester has some imports left over that operate on directory traversal, assuming it is contained within react-native sources. This change makes these imports relative to react-native, enabling usage outside of the RN repo.
Relates to https://github.com/microsoft/react-native-windows/issues/6210
## Changelog
[Internal] [Fixed] - Avoid File Structure Assumptions in RNTester Imports
Pull Request resolved: https://github.com/facebook/react-native/pull/30141
Test Plan: Validated we can bundle and flow-check both iOS + Android
Reviewed By: cpojer
Differential Revision: D24259628
Pulled By: appden
fbshipit-source-id: 0c21b5d354b01785d8402599da3b0a5be81b4c6d
Summary:
Microsoft’s RN for macOS fork supports the Hermes engine nowadays https://github.com/microsoft/react-native-macos/pull/473. As a longer term work item, we’ve started moving bits that are not invasive for iOS but _are_ a maintenance burden on us—mostly when merging—upstream. Seeing as this one is a recent addition, it seemed like a good candidate to start with.
As to the actual changes, these include:
* Sharing Android’s Hermes executor with the objc side of the codebase.
* Adding a CocoaPods subspec to build the Hermes inspector source and its dependencies (`Folly/Futures`, `libevent`).
* Adding the bits to the Xcode build phase script that creates the JS bundle for release builds to compile Hermes bytecode and source-maps…
* …coincidentally it turns out that the Xcode build phase script did _not_ by default output source-maps for iOS, which is now fixed too.
All of the Hermes bits are automatically enabled, on macOS, when providing the `hermes-engine-darwin` [npm package](https://www.npmjs.com/package/hermes-engine-darwin) and enabling the Hermes pods.
## Changelog
[General] [Added] - Upstream RN macOS Hermes integration bits
Pull Request resolved: https://github.com/facebook/react-native/pull/29748
Test Plan:
Building RNTester for iOS and Android still works as before.
To test the actual changes themselves, you’ll have to use the macOS target in RNTester in the macOS fork, or create a new application from `master`:
<img width="812" alt="Screenshot 2020-08-18 at 16 55 06" src="https://user-images.githubusercontent.com/2320/90547606-160f6480-e18c-11ea-9a98-edbbaa755800.png">
Reviewed By: TheSavior
Differential Revision: D23304618
Pulled By: fkgozali
fbshipit-source-id: 4ef0e0f60d909f3c59f9cfc87c667189df656a3b
Summary:
## 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
-->
This PR aims to migrate the RNTester App to `packages` directory. But is currently, open to inspect the CI issues and resolve the merge conflicts.
Currently done
- Working on iOS
- Working on Android
- Detox Tests working on iOS
Need to work on
- Errors generated by the CI builds
[General] [Changed] - Migrated the RNTester App to the packages directory.
Pull Request resolved: https://github.com/facebook/react-native/pull/29567
Test Plan: It runs on both ios and android for now and the detox iOS builds are working.
Reviewed By: cpojer
Differential Revision: D23034761
Pulled By: rickhanlonii
fbshipit-source-id: e04bb06e1c7ef15d340206090d1575a871b9e6f5
Christian Falch
Tim Yung
Dawid Małecki
Rubén Norte
Jakub Piasecki
Nick Gerleman
Riccardo Cipolleschi
Kudo Chien
Oskar Kwaśniewski
Moti Zilberman
Nick Gerleman
Saad Najmi
Saad Najmi
Ruslan Lesiutin
Christoph Purrer
Héctor Ramos
Luis Santana
Chaoshuai Lu
Phillip Pan
Samuel Susla
Andres Suarez
Nicola Corti
Tim Yung
Kevin Gozali
Peter Argany
Héctor Ramos
Ramanpreet Nara
Christoph Nakazawa
Lulu Wu
Nick Gerleman
Eloy Durán
stealthanthrax
