Summary:
The method that would restore these files was removed in https://github.com/facebook/react-native/pull/34846. The action performed by `saveFilesToRestore` is no longer necessary (thanks kelset for pointing this out).
Changelog: [internal]
Reviewed By: cortinico
Differential Revision: D41003911
fbshipit-source-id: bbc057ac450e7f134c4664173291ca56c18f1b17
Summary:
This change moves the default new application template in OSS from Flow to TypeScript. This better aligns with the communities usage, and aligns to the great work that has been happening for TS codegen and built-in types. This used [`react-native-community/react-native-template-typescript`](https://github.com/react-native-community/react-native-template-typescript) as a main reference, maintained by radko93. A few things are different:
1. Updated `types/*` devDependencies to match bumped libraries (e.g. Jest 26 to 20).
2. Removed `types/react-native`
3. Removed explicit `moduleFileExtensions` to Jest config in package.json (TS and TSX and added by default in current versions)
4. Removed overrides to eslint config to disable `no-shadow` and `no-undef`, since this was fixed in the underlying eslint config with https://github.com/facebook/react-native/pull/32644 and https://github.com/facebook/react-native/pull/32655
5. Re-translated `App.js` to be a direct translation (e.g. still a raw function instead of React.FC which is sometimes discouraged)
6. Aligns completely to `tsconfig/react-native` maintained configuration (We no longer have the opinionated override of `skipLibCheck`). The important settings are that `strict` is enabled for, but `allowJS` is also enabled to let users import JS modules without anything unexpected. `esModuleInterop` is enabled, which is needed for consistency with Babel import transformations used by Metro. Consistent with our [current documentation](https://reactnative.dev/docs/typescript) built against the community template, `tsc` will typecheck your code without emitting(building) anything.
[Documentation](https://reactnative.dev/docs/typescript) will need to be updated as a followup.
Changelog:
[General][Changed] - Use TypeScript by default for new applications
Pull Request resolved: https://github.com/facebook/react-native/pull/35165
Test Plan: Added usage of `tsc` and `jest` when validating a newly built app. Passes in CircleCI `test_js` job. This also meant removing some cases of copying packages into the users app to pull in the root Metro config (we seem to be able to use the template Metro config consistent with what real apps would get).
Reviewed By: cortinico
Differential Revision: D40911951
Pulled By: NickGerleman
fbshipit-source-id: 15994534235695e91cf994ad06ba2183dfc89a50
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35166
The Hermes source code is not included in the RN npm package. This piece of code is a remnant from an early experimentation into integrating Hermes more tightly with React Native. We ended up using a combination of the scripts in `scripts/hermes` to fetch the source code from GitHub and relying on prebuilts for stable releases.
Added `strict()` flag to ensure the script fails immediately if an unrecognized flag is passed.
Avoid logging temp publishing folder value to console when `--help` is used.
Changelog: [internal]
Reviewed By: cortinico
Differential Revision: D40918939
fbshipit-source-id: 2e62ab16467c4c67f03efdf5211a156cb70e0b11
Summary:
This PR is a follow up of https://github.com/facebook/react-native/pull/35075 and 1546666a6d to ensure that even in the local e2e testing scenario the new maven approach is followed - without this, RNTestProject on Android won't work, like so:
<img width="1905" alt="Screenshot 2022-10-27 at 12 15 38" src="https://user-images.githubusercontent.com/16104054/198334105-30fb2037-4e7c-4814-8c3f-2412ba0bd49f.png">
And iOS will always build everything from source every time.
This PR addresses both by generating the artifacts locally, and passing them to RNTestProject as if they were coming from a url (mimicking as closely as possible the behaviour for the final user)
In doing so, there's been some refactoring to prep the ground for follow up work.
* refactor CI to rely less on scripts directly in the CircleCI config, but invoke .js ones
* we should be able to trigger more the "manual" artifacts generation so that it will only happen once between RNTester and RNTestProject, and we can pass existing artifacts to the other flows.
* once all of this in place, a very good improvement would be to be able to download the maven artifacts kind of like nightlies and stables do. This will only be viable by checking that there's no local changes, after which there needs to be logic to pull down from CircleCI the artifacts based on git commit <-> circleCI job references.
---
While at it, I've also fixed the hermes-engine podspec logic for detecting if it's on CI: basically the local e2e script needs to align with the changes done here: 4b51207735
but as you can see there, the condition was actually inconsistent across the various files, so realigned to `CI === 'true'`. We probably didn't catch that so far 'cause the other condition in the hermes podspect (existence of `hermestag_file`) is only true on release branches and this new logic has not been in any release branches yet.
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[Internal] [Fixed] - add logic to local e2e script to handle maven local for iOS and Android accordingly
Pull Request resolved: https://github.com/facebook/react-native/pull/35104
Test Plan:
Run ` yarn test-e2e-local -t RNTestProject -p Android` successfully.
Run ` yarn test-e2e-local -t RNTestProject -p iOS` successfully. On the pod install stage, you will see `[Hermes] Using pre-built Hermes binaries from local path.`
Reviewed By: dmytrorykun
Differential Revision: D40893239
Pulled By: cipolleschi
fbshipit-source-id: a31217ec4f177383c62292d00fabc4cbe4391cfd
Summary:
Improving test coverage in anticipation of some changes being made to `hermes-utils.js`.
Moved test scripts to `hermes/__tests__` and grouped related tests.
We have been delegating some of the work to local binaries via `execSync`, which can be hard to mock or test. We now use a proxy `delegateSync` method that uses `spawnSync` internally to break down the invocation into `command`, `arguments`, `options`. Instead of simply mocking based on the command being executed, we can now conditionally mock based on the arguments being passed.
Added a `createTarballFromDirectory` method. This can be used later when creating different tarballs.
Added `populateMockFilesystemWithHermesBuildArtifacts()` to mock the filesystem state after Hermes has been built.
Changelog: [internal]
Reviewed By: cipolleschi
Differential Revision: D40871802
fbshipit-source-id: 4348d3c38926ec7eb13d794040a9040010879f58
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35162
The dSYMs for Apple will not be distributed as part of the prebuilts tarball. They can still be included in the tarball by passing a `-d` flag to the create-tarball script.
Changelog: [internal]
Reviewed By: cipolleschi
Differential Revision: D40813679
fbshipit-source-id: 26dee8251684c5ecad649ccd27ce688cfe88ec8f
Summary:
## Context
If React Native is built from *main* of any non-stable commit, then Hermes is built from source. The build is performed by `build-ios-framework.sh` and `build-mac-framework.sh` scripts in `hermes-engine.podspec` `prepare_command` stage. Since those scripts have no access build target information, they build all possible architectures and platforms just in case. That takes ages.
## Solution
The idea is to integrate build script into Xcode *run script* phase, and use build target information to build Hermes for active architecture only.
## Implementation
- Existing behaviour remains unchanged for local tarball and remote prebuild cases.
- `build-hermesc-xcode.sh` builds Hermesc as `hermes-engine.podspec` `prepare_command`. Default build location is `react-native/sdks/hermes-engine/build_host_hermesc`.
- `build-hermes-xcode.sh` builds Hermes in 'Build Hermes' Xcode script phase. It uses `$PLATFORM_NAME`, `$CONFIGURATION`, `$ARCHS`, `$IPHONEOS_DEPLOYMENT_TARGET` and `$MACOSX_DEPLOYMENT_TARGET` environment variables to configure cmake project so it builds only active architecture. The script also gets RN version, *cmake* path and *hermesc* path from the podspec.
- `copy-hermes-xcode.sh` copies Hermes.framework inside the app bundle. This script phase is added to the user app target in a `post_install` hook, after pods are integrated in a user project.
- `OTHER_LDFLAGS -framework "hermes"` added to the user project to enable linking against Hermes.framework.
- If `HERMES_OVERRIDE_HERMESC_PATH` is set, then Hermesc building is skipped, and `HERMES_OVERRIDE_HERMESC_PATH` is used for `build-hermes-xcode.sh`.
- `HERMES_CLI_PATH` is injected into user project config to enable Hermes source maps in `react-native-xcode.sh`.
## Things that didn't work
- *Running build-hermesc-xcode.sh in Xcode run script phase*. This doesn't work because Hermesc is supposed to be built for macos, and if build target is ios, then Xcode configures environment in such a way that Hermesc build fails.
- *Installing Hermesc into CocoaPods download folder*. So it then ends up in `Pods/hermes-engine/build_host_hermesc`, and all the housekeeping is handled by CocoaPods. This doesn't work because cmake uses absolute paths in a configured project. If configured project is moved to a different location, nothing builds.
- *Installing Hermesc directly into Pods/hermes-engine*. This doesn't work because CocoaPods runs prepare_command before Pods folder clean up, and everything gets wiped.
## Known issue
- If `Pods/hermes-engine` is manually removed, then `sdks/hermes-engine/build_host_hermesc` must also be removed before running `pod install`. Otherwise cmake will complain about stale cache:
```
CMake Error: The source "<CocoaPodsCache>/hermes-engine/<hash2>/CMakeLists.txt" does not match the source
"<CocoaPodsCache>/hermes-engine/<has1>/CMakeLists.txt" used to generate cache. Re-run cmake with a different source directory.
```
## Benchmark
MacBook M1 2021 32 GB.
```
export REACT_NATIVE_PATH=~/fbsource/xplat/js/react-native-github
cd $REACT_NATIVE_PATH/packages/rn-tester
pod install
rm -rf $REACT_NATIVE_PATH/sdks/hermes-engine/build_host_hermesc
cd $REACT_NATIVE_PATH/packages/rn-tester/Pods/hermes-engine
echo 't1=$(date +%s); $@; t2=$(date +%s); diff=$(echo "$t2 - $t1" | bc); echo Operation took $diff seconds.' > /tmp/benchmark.sh
```
```
# Before
export BUILD_TYPE=Debug
export JSI_PATH=$REACT_NATIVE_PATH/ReactCommon/jsi
export RELEASE_VERSION=1000.0
export IOS_DEPLOYMENT_TARGET=iphonesimulator
export MAC_DEPLOYMENT_TARGET=12.6
cd $REACT_NATIVE_PATH/packages/rn-tester/Pods/hermes-engine
. /tmp/benchmark.sh $REACT_NATIVE_PATH/sdks/hermes-engine/utils/build-ios-framework.sh
# Operation took 252 seconds
. /tmp/benchmark.sh $REACT_NATIVE_PATH/sdks/hermes-engine/utils/build-mac-framework.sh
# Operation took 179 seconds
```
```
# After
. /tmp/benchmark.sh source $REACT_NATIVE_PATH/sdks/hermes-engine/utils/build-hermesc-xcode.sh $REACT_NATIVE_PATH/sdks/hermes-engine/build_host_hermesc
# Operation took 59 seconds.
. /tmp/benchmark.sh xcodebuild -workspace $REACT_NATIVE_PATH/packages/rn-tester/RNTesterPods.xcworkspace -scheme hermes-engine
# Operation took 106 seconds.
```
|Before|||After|||
|--|
|iOS framework (s)|Mac framework (s)|Total (s)|Hermesc (s)|Target-specific framework (s)|Total (s)|
|252|179|431|59|106|**165 (-266) (-61%)**|
The performance win is fixed, and does not depend on the project size and structure.
As an example, this is how these changes affect build time of RNTester.
|Before||||After|||
|--|
||Pod install (s)|Xcode build (s)|Total (s)|Pod install (s)|Xcode build (s)|Total (s)|
|Clean build|1219|132|1352|734 (-485)|249(+117)|**983 (-369)**|
|Incremental build|82|30|112|105 (+23)|**34 (+4)**|139 (+27)|
The most important values here are the total clean build time and the incremental Xcode build time. The first one went down by 369 seconds, the second one went up by 4 seconds. I consider it a reasonable tradeoff.
The extra 4 seconds in the incremental Xcode build time can potentially be mitigated by setting up output file lists for the new script phases.
allow-large-files
Changelog:
[iOS][Changed] - Hermes is integrated into Xcode build.
Reviewed By: hramos
Differential Revision: D40063686
fbshipit-source-id: e6993d62225789377db769244bc07786cc978a27
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35160
With the simplified migration to the new arch, we are offering a function in cocoapods that takes care of configuring all the dependencies for libraries.
That function was not setting the proper version of C++ for the library. This could lead to build problems.
This Diff make sure that the libraries that are created with this function call have the proper C++ version.
NOTE: we already have a post install hook that was setting the the proper C++ version, but that was only working for the project. Plus, we can't read that version from the React-Core podspec because at the podspec definition time, cocoapods has not read that yet. Therefore, I just hardcoded the C++ version on top of the file, so it will be easier to update if we decide to change it.
## Changelog
[iOS][Fixed] - Make sure that libraries created with `install_modules_dependencies` has the right C++ version.
Reviewed By: dmytrorykun
Differential Revision: D40894561
fbshipit-source-id: a5187be2d85888a335d4c033f16fdacaf2c945f9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35156
There are two tarballs: the source code for Hermes that is downloaded from GitHub, and the hermes-runtime-darwin-{}-v{}.tar.gz tarball with prebuilt artifacts that is built in CI.
Renamed some methods to make it clearer which tarball they work with.
Changelog: [internal]
Reviewed By: cipolleschi, dmytrorykun
Differential Revision: D40812290
fbshipit-source-id: a2c865e1d1461829fe8d468f52deeb55f3565cb0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35028
**This Diff require a bump in the react-native-codegen (including this [commit](7680bdeb4f)) to work**
This diff sets up iOS and Android to pass their platform to the codegen so that we can have platform-specific specs.
## Changelog
[General][Added] - Enable platform-specific Codegen Specs
Reviewed By: cortinico
Differential Revision: D40516395
fbshipit-source-id: 0624f0bfb93c90f78131a605a4847e780783bbaf
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35109
This is just a safety check to make sure we don't accidentally
publish a 1.x or a 1000.x version on Maven Central by mistake.
Changelog:
[Internal] [Changed] - Gate the Maven Central publishing to 0.x version.
Reviewed By: mdvacca
Differential Revision: D40767782
fbshipit-source-id: 58f2906c3b01bfd0fd388a300ba303b289633d4e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35108
I've rewritten the comment in the android/app/build.gradle.
They were really old, contained wrong links and most of the people ignored it.
I've also moved the enabling of Hermes to the `gradle.properties` file.
RNGP still supports the old method, but we must be sure that we notify
library authors if they were reading project.ext.react.enableHermes in the past
(also the website needs to be updated).
I've also cleaned up the CircleCI setup as now we can specify Hermes enabled/disabled
via the CLI (this will also make easier to do e2e testing).
Changelog:
[Android] [Changed] - Cleanup the template documentation after RNGP & hermesEnabled to gradle.properties
Reviewed By: cipolleschi
Differential Revision: D40762872
fbshipit-source-id: 2c09245e0a923faac53cc6c8a89e99788ae47f8a
Summary:
This remove a flag to effectively go publishing to Sonatype.
The idea was to protect us against accidentally publishing a nightly as a stable release.
We need to remove this before RC0
Changelog:
[Internal] [Changed] - Remove the --dry-run gate from publishing to Sonatype
Reviewed By: cipolleschi
Differential Revision: D40687038
fbshipit-source-id: e6821905f41899430813f9575f17a5068b05a9bb
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35075
This diff updates the New App template for Android to use the React Native Gradle Plugin.
With this we can:
1. Get rid of all the C++ code.
2. Remove a lot of New Architecture logic in the build.gradle
3. Reuse the prebuilts of React Native/Hermes via prefab
Changelog:
[Android] [Changed] - Update the template to use RNGP
Reviewed By: cipolleschi
Differential Revision: D40673732
fbshipit-source-id: 70935248993d1e24904c982e75f12ad580faa9d8
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:
Move JSC and Hermes CocoaPods configuration to scripts/cocoapods/jsengine.rb.
This file provides a setup_jsc! function and a setup_hermes! function that will configure the necessary pod dependencies for each of the supported JavaScript engines.
Currently, the JSI and JSC pods are installed in both cases. This will likely change in upcoming changes to how Hermes and JSC are configured.
Changelog: [internal]
Reviewed By: dmytrorykun
Differential Revision: D40459234
fbshipit-source-id: d6c89c7f650b1efcce5622594db7fd726eafc2bc
Summary:
The React-Hermes and hermes-engine headers are only needed when Hermes is enabled.
Changelog: [internal]
Reviewed By: cipolleschi
Differential Revision: D40451162
fbshipit-source-id: d38830f8abe57a91798e216d7930bb7add483899
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:
Pull Request resolved: https://github.com/facebook/react-native/pull/35034
Currently, when creating an app using the command:
`npx react-native init MyApp --version nightly`
iOS fails to install the dependencies because it does not find a proper tarball to run Hermes.
This diff solve the problem by fetching the Hermes tarball that is created by the CI while building the nightly.
## Changelog:
[iOS][Fixed] - Make the nightly work with the proper Hermes tarball
Reviewed By: cortinico
Differential Revision: D40512418
fbshipit-source-id: f510f84be9f19807236091687df5e13961103318
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35015
React Native releases are cut every few months. Without testing, the workflow is prone to breakage.
Dry-run the release workflow on every commit in order to surface any issues as they are introduced instead of at release time.
Fixed issues that surfaced during testing of this workflow:
- Upload both Hermes tarballs
Changelog: [internal]
Reviewed By: mdvacca
Differential Revision: D40483764
fbshipit-source-id: 5ca6bd4dcdfd64c24882ffb202edbfd701efd462
Summary:
It seems like CircleCI is not handling well env variables with \n in it.
I'm moving it over to a base64 encoded string and I'm extending the publish
scripts to base64 decode the key.
Changelog:
[Internal] [Changed] - Unbreak Nightly job by providing a GPG key as base64 encoded.
Reviewed By: cipolleschi
Differential Revision: D40426438
fbshipit-source-id: a60a7e7ad71580e81e675c84008d2712712e42a6
Summary:
The jsi library itself is `jsi/jsi.{h,cpp}`. JSIDynamic provides support for converting between folly::dynamic and jsi::value, independent of the jsi library.
Changelog:
[iOS][Changed] Moved JSIDynamic out of React-jsi and into React-jsidynamic
Reviewed By: cipolleschi, dmytrorykun
Differential Revision: D40334023
fbshipit-source-id: d2c69e7afb7f43f93080301b88c81e1fa46279d7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34983
This sets up our CircleCI logic to publish artifacts to Maven Central.
I will check if tomorrow's nightly successfully landed on Maven Central
Snapshot repository.
I've added a --dry-run to the the close and release step of the publishing
to avoid accidentally publishing to Maven Central. We'll remove this if
we decide to go with the Maven Central publishing.
Changelog:
[Internal] [Changed] - Configure CircleCI to publish artifacts to Maven Central
Reviewed By: jacdebug, huntie
Differential Revision: D40377691
fbshipit-source-id: 36a74074ea95097bb7268352e40f4d2670f3cd65
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34884
Xcode 14 is now stable. Updating CI to use latest Xcode command line tools.
The Circle CI 14.0.1 container ships with Ruby 2.7.6 and CocoaPods 1.11.3, see full manifest here: https://circle-macos-docs.s3.amazonaws.com/image-manifest/v8824/index.html
Changelog: [iOS][Changed] Bump to Ruby 2.7.6 and CocoaPods 1.11.3
Reviewed By: mdvacca
Differential Revision: D40148796
fbshipit-source-id: b1eab68e159ec3237ff2ef596163b73fc1e511e4
Summary:
ios debug archiving build will generate ip.txt that will leak metro server address for other people testing.
moreover, it will slow down launch time for metro server availability to wrong address.
this pr introduce `SKIP_BUNDLING_METRO_IP` to prevent ip.txt generation.
## 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
-->
[Internal] [iOS] [Changed] - introduce SKIP_BUNDLING_METRO_IP to skip ip.txt generation
Pull Request resolved: https://github.com/facebook/react-native/pull/31829
Test Plan:
### Classic build will generate ip.txt
```sh
xcodebuild -workspace RNTesterPods.xcworkspace -scheme RNTester -configuration Debug -sdk iphoneos -destination 'generic/platform=iOS'
find $HOME/Library/Developer/Xcode/DerivedData/RNTesterPods-* -name 'ip.txt'
```
this will find the ip.txt
### Specify `SKIP_BUNDLING_METRO_IP=1` will not generate ip.txt
```sh
SKIP_BUNDLING_METRO_IP=1 xcodebuild -workspace RNTesterPods.xcworkspace -scheme RNTester -configuration Debug -sdk iphoneos -destination 'generic/platform=iOS'
find $HOME/Library/Developer/Xcode/DerivedData/RNTesterPods-* -name 'ip.txt'
```
this will NOT find the ip.txt
Reviewed By: hramos
Differential Revision: D40095785
Pulled By: hramos
fbshipit-source-id: 0c913f078e683879e07e9ce3306e899d631206b2
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34875
Create common script for generating a Hermes tarball after Hermes is built from source.
Use after building Hermes from source to create a tarball of the resulting build artifacts. The path to the tarball can be passed to CocoaPods via a `HERMES_ENGINE_TARBALL_PATH` envvar in order to use these pre-built Hermes artifacts when installing the `hermes-engine` pod with `pod install`.
Use in Circle CI when creating a Hermes tarball for caching and for use in stable React Native releases.
Usage:
```
pod install
# When Hermes is built from source via CocoaPods, the build artifacts will be located in the Pods directory for hermes-engine
node ./scripts/hermes/create-tarball.js \
--inputDir ./sdks/hermes \
--buildType Debug \
--releaseVersion 1000.0.0 \
--outputDir .
```
Changelog: [Internal]
Reviewed By: cipolleschi
Differential Revision: D40124378
fbshipit-source-id: f9712e87526ccc737afac4599b0ab0a7bb3f3956
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34897
This [commit](7680bdeb4f) added the possibility to create Codegen specs that are platform specific.
However, it also modifies how the codegen is invoked and we need to publish a new version of the `react-native-codegen` package on NPM before we can use that feature.
## Changelog:
[General][Fixed] - Remove usage of the codegen spec filtering until we publish a new version of the codegen.
Reviewed By: robhogan
Differential Revision: D40176447
fbshipit-source-id: 20be630dec3dcd7efb9fd510c6cf9f2c161f906a
Summary:
This diff helps the library maintainer to keep their spec file platform specific if some specs make no sense in one platform or in the other.
We are filtering the spec files when we need to create the Schema.
The diff modifies also the call sites in the `scripts` (for iOS) and in the `gradle-plugin` (for Android).
It also adds tests for the new functions in the CLI.
The change is completely additive and it should not change any pre-existing behaviour.
## Changelog
[General][Added] - Add support for platform-specific specs
Reviewed By: cortinico
Differential Revision: D40008581
fbshipit-source-id: b7fcf6d38f85fe10e4e00002d3c6f2910abdbe35
Summary:
This is inspired by the Expo workaround d970a9ecbb to address an issue that cocoapods has with Xcode 14: https://github.com/CocoaPods/CocoaPods/issues/11402
This wants to address this https://github.com/facebook/react-native/issues/34673 in a way that we can also cherry-pick on the 0.70 branch.
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[iOS] [Fixed] - add xcode 14 workaround (turn off signing resource bundles) for `React-Core`
Pull Request resolved: https://github.com/facebook/react-native/pull/34826
Test Plan:
Tested locally by opening RNTester via Xcode 14.0.1, and targetting my iPhone as device. After applying the patch, the error for React Core AccessibilityResources disappears.
Also, added ruby test for new patch.
Reviewed By: hramos
Differential Revision: D40063828
Pulled By: hramos
fbshipit-source-id: e10d5b6a917a6a7cbacd14ecfdac55e60e46c6f8
Summary:
I'm not sure why, but my commit 97f5ef05e6 landed despite the PR still having a couple of merge conflicts from after Kudo's PR https://github.com/facebook/react-native/issues/34846 being merged.
What happened is that basically it just "overwrote" those chances, so this PR is just a fix for that.
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[Internal] [Changed] - re-adding Kudo's fix for nightly build
Pull Request resolved: https://github.com/facebook/react-native/pull/34861
Test Plan: N/A
Reviewed By: cipolleschi
Differential Revision: D40059290
Pulled By: cortinico
fbshipit-source-id: 38e495a0dbecd39e836d15aa2a1a30e7354d9813
Summary:
This is a long time coming effort to improve the situation around the local e2e script that in the release crew: the current bash-based script is quirky at best, and what you end up generating as a sample project is not really a true sample project. This is where this PR comes in: it migrates the flow from `./scripts/test-manual-e2e.sh` to `yarn test-e2e-local <options>`.
Here's the current shape of the options:
```sh
Options:
--help Show help [boolean]
--version Show version number [boolean]
-t, --target [choices: "RNTester", "RNTestProject"] [default: "RNTester"]
-p, --platform [choices: "iOS", "Android"] [default: "iOS"]
-h, --hermes [boolean] [default: true]
```
The idea is to change it so that you can just run the script, and it will do that one specific thing "well", without the tester needing to do anything aside from actually testing the app once it's open.
Some of the key changes:
* tries to stick to the patterns of the other established *.js based scripts, in terms of tooling and approach (and even refactor parts that can be shared with other scripts) - like the android artifacts generation
* no need to start the android emulator on the side
* no need to start Metro on the side
* RNTester iOS will open up on the simulator (no Xcode open that then you need to press)
Things that still need work:
* see the #fixme and #todo in comments
* because we rely on exec, the output sent back is not formatted/shaped correctly so it's a bit more noisy/chaotic - but can't handle it right now because the package we use doesn't allow it - see https://github.com/shelljs/shelljs/issues/86
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[Internal] [Changed] - Migrate bash E2E local testing script to new JS based command
Pull Request resolved: https://github.com/facebook/react-native/pull/34513
Test Plan:
To test the script, you can run it passing the options showed above; this is the current situation:
* RNTester iOS Hermes ✅
* RNTester Android Hermes ✅
* RNTester iOS JSC ✅
* RNTester Android JSC ✅
* RNTestProject Android Hermes ✅
* RNTestProject iOS Hermes ✅
* RNTestProject Android JSC ✅
* RNTestProject iOS JSC ✅
Reviewed By: cortinico
Differential Revision: D39814692
Pulled By: cortinico
fbshipit-source-id: d4791798aaad764c6a3757269b7636f847ccf2ca
Summary:
There are two issues from nightly builds.
#### 1. `VERSION_NAME=1000.0.0-main` in _ReactAndroid/gradle.properties_
the solution is to remove unused _ReactAndroid/gradle.properties_ git revert when publishing package.
#### 2. `pod install` error from downloading hermes, e.g. the url is unavailable. `https://github.com/facebook/react-native/releases/download/v0.0.0-20221002-2027-2319f75c8/hermes-runtime-darwin-debug-v0.0.0-20221002-2027-2319f75c8.tar.gz`
fix _hermes-engine.podspec_ to support nightly build and build hermes from main branch.
## Changelog
[General] [Fixed] - Fix nightly build issues
Pull Request resolved: https://github.com/facebook/react-native/pull/34846
Test Plan:
1. i cannot fully test publish-npm.js workflow and it stops at `npm publish`. i can just check at this moment, the _ReactAndroid/gradle.properties_ is right.
2. create a `npx react-native init` project and `yarn add react-native@nightly`. patch `node_modules/react-native/sdks/hermes-engine/hermes-engine.podspec` and try `pod install`
Reviewed By: cipolleschi
Differential Revision: D40021649
Pulled By: cortinico
fbshipit-source-id: c9e2701e524f4b16eab6f2c72b5cfa34883082c3
Summary:
Moves the `retry3` utility function into its own file so that it can be reused in other steps that are not related to Android.
Changelog:
[Internal]
Reviewed By: rickhanlonii, cipolleschi
Differential Revision: D39889996
fbshipit-source-id: bf79cc19ad6178af0a0d8117a81116e0c32f4333
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34802
This removes the old way of consuming `libreact_render_debug.so` from
`Android-prebuilt.cmake` to using Prefab which is natively supported
by the Android pipeline.
Changelog:
[Internal] [Changed] - Move `react_render_debug` to be consumed via prefab
Reviewed By: cipolleschi
Differential Revision: D39849622
fbshipit-source-id: 45451dfe92ecce94d1b466094baae05a75ed803f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34776
CocoaPods is not used when Hermes is built in Circle CI, so we cannot rely on the React Native CocoaPods scripts to be loaded.
The get_hermes_build_type function is removed from the RN CocoaPods scripts and in its place, the ENV['PRODUCTION'] envvar is accessed directly.
Changelog: [Internal]
Reviewed By: cipolleschi
Differential Revision: D39778190
fbshipit-source-id: 12083b7b4533b4ad7bb7a08612883983a0583616
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34761
Separate debug and release tarballs are built in CI. Use the appropriate Hermes artifacts tarball when building hermes-engine.
Add hermes.rb tests.
Changelog:
[iOS] [Changed] - Remove debugger from Hermes when building for release
Reviewed By: cipolleschi
Differential Revision: D39698499
fbshipit-source-id: e6b10d34c7f94c2f86fc47d8b97466011aaa75cc
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34746
The changes made in
https://github.com/facebook/react-native/pull/34694
introduced the need to have the env variable TMP_PUBLISH_DIR for the publishing and set-rn-version scripts to work.
This break any usage of set-rn-version when the env variable is not set upfront.
With this change, we are creating a temp folder in the scope that requires it (e.g. set-rn-version.js) and then passing the path to the save/revert functions.
## Changelog
[Internal] [Added] - Do not depend on an ENV variable when publishing and setting the RN version.
Reviewed By: cipolleschi
Differential Revision: D39683565
fbshipit-source-id: 21d85d1c16c4cb7324636ceb5eba626ff8cbb775
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34754
This Diff is the second step of enabling the CodeGen to parse and generate a NativeState for the components.
The feature has been largely requested by the OSS community but it could be also helpful for people in Meta.
## Changelog
[General][Added] - Always generate an empty NativeState for Fabric Components
Reviewed By: cortinico
Differential Revision: D39696435
fbshipit-source-id: e24768af78f59696c0b4db009e8065bb5c89316b
Summary:
This PR adds [verdaccio](https://github.com/verdaccio/verdaccio) to release packages in the `packages` directory during the E2E test on CI.
The rationale behind this is the following:
- Firstly, we wanted to push the [monorepo RFC](https://github.com/react-native-community/discussions-and-proposals/pull/480). We hit an issue when renaming the packages to follow the same convention caused by the e2e test using the template to fail. This is because the template installs packages from the live version of npm – and if you just rename a package in a given PR without releasing it, the package understandably can't be installed since it's not published, yet – as you can see [here](https://app.circleci.com/pipelines/github/facebook/react-native/15286/workflows/149df51f-f59b-4eb3-b92c-20c513111f04/jobs/282135?invite=true#step-108-283).
- Secondly, the current e2e test on `main` does not actually test the latest code of the packages in the `packages` directory as it simply downloads the latest versions from npm. This creates a divide between what's tested and what users should expect when using nightlies or when a new minor is released.
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[Internal] [Changed] - Use verdaccio for template e2e test
Pull Request resolved: https://github.com/facebook/react-native/pull/34577
Test Plan: `test_js` CI check should pass. Additionally, I have temporarily updated the [PR](https://github.com/facebook/react-native/pull/34572) renaming `assets` to `assets-registry` to include the verdaccio changes – the `test_js` passes there, additionally proving merging this PR will unblock us with the rename PRs.
Reviewed By: cipolleschi
Differential Revision: D39723048
Pulled By: cortinico
fbshipit-source-id: aeff3811967360740df3b3dbf1df50e506fb72d8
Summary:
Checking if Hermes is enabled is failing because there is no `podfile.lock` file in the directory where this script is executed and `USE_HERMES` will be set to `false` which will prevent building Hermes binary jsbundle.
## Changelog
[iOS] [Fixed] - `HERMES_ENABLED` check fixed in react-native-xcode.sh
Pull Request resolved: https://github.com/facebook/react-native/pull/34675
Test Plan:
1. Enable Hermes
2. Make a release build
3. Verify the `main.jsbundle` file is Hermes binary bundle
Reviewed By: cortinico
Differential Revision: D39686608
Pulled By: cipolleschi
fbshipit-source-id: 237c77ced484d4ab77e576c7a2bb7b6826228017
Summary:
## Changelog
[General] [Added] - Add `types` folder to house TypeScript types.
Release TypesScript types with react-native and eventually deprecate [types/react-native](https://www.npmjs.com/package/types/react-native).
The current plan is to release types/react-native for 0.70 and 0.71 while also maintaining types here. This will result in some double maintenance until 0.72 but will give community time to move off of types/react-native.
After this lands, there have been changes on `main` of types that we need to update. Then, when we release 0.71 from DefinitelyTyped, we can simply copy over the `types` folder from this repo.
Pull Request resolved: https://github.com/facebook/react-native/pull/34614
Test Plan:
`yarn run test-typescript` for linting types
* Created a new project using the TS template and my local clone of `react-native` on this branch.
`npx react-native init MyTSApp --version <path-to-my-local-rn-repo> --template react-native-template-typescript`
* Updated the `package.json` to remove `types/react-native`
* Deleted my node_modules and re-ran yarn
* Opened MyTSApp in VSCode and verified the type suggestions appeared and cmd+click to defnitions took me to the node_module dependency `react-native/types`
## Danger is failing on this PR and it's expected
as it runs off the changes on `main`. [This is expected](https://docs.github.com/en/github-ae@latest/actions/using-workflows/events-that-trigger-workflows?fbclid=IwAR2_AE0Jwndt8Gu-iTQnxGxLJq7nakbi7sz8jwZ6U62JWLSdcZuvjcQ6WvE#pull_request_target). However testing it locally passes. Once merged, and these changes are on `main`, danger will pass again.
```
$ react-native/packages/react-native-bots
❯ yarn danger pr https://github.com/facebook/react-native/pull/34614
yarn run v1.22.19
$ ..react-native/node_modules/.bin/danger pr https://github.com/facebook/react-native/pull/34614
Starting Danger PR on facebook/react-native#34614
Danger: ✓ found only warnings, not failing the build
## Warnings
🔒 package.json - <i>Changes were made to package.json. This will require a manual import by a Facebook employee.</i>
✨ Done in 13.24s.
```
Reviewed By: mdvacca
Differential Revision: D39479137
Pulled By: lunaleaps
fbshipit-source-id: 1d506f812d566b783b6e79104cd6339b077a42a7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34713
Changelog: [Internal] - Fix up missing bots usage after we moved everything to packages/react-native-bots in 767f8e0249
Reviewed By: NickGerleman
Differential Revision: D39583230
fbshipit-source-id: 6cc6b7923e67139dc3c81dfe0c39005dde905248
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34694
TL;DR Relax the assumption of having git to build the RN NPM package.
We do have two CI Systems: CircleCI for OpenSource and Sandcastle for Internal. It's crucial that the two CIs are aligned.
We currently don't have a way to test the new app template on Sandcastle for Android & iOS.
This results in scenarios where internal Diffs gets landed and break the public CI externally.
This is preparation work to then be able to build the RN NPM package in Sandcastle (which will be done in a follow-up diff).
With this we also introduce the restoring of all the changed files after the publishing script is done.
## Changelog
[Internal] [Added] - Made it possible to create publishing NPM packages in Sandcastle.
Reviewed By: cortinico, cipolleschi
Differential Revision: D39467471
fbshipit-source-id: b0de88a768b8a2fb798dd684fa8f97f4d0acb751
Summary:
This Diff adds a couple of APIs to the `react_native_pods.rb` file to simplify further the migration to the New Architecture for the iOS app.
Specifically, it aims to simplify [this](https://reactnative.dev/docs/next/new-architecture-app-intro#ios---build-the-project) steps by offering a RN-managed min version and creating the .xcode.env file for the user if it is missing.
## Changelog
[iOS][Added] - Add new API to simplify app migration
Reviewed By: cortinico
Differential Revision: D39469599
fbshipit-source-id: f0323e86c83c2731671fcd5bb4288071304bb43b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34670
Users can enable the New Architecture on iOS in two way: using the `RCT_NEW_ACRH_ENABLED` env variable or setting the `new_arch_enabled` flag when invoking the `use_react_native` function.
We need to set the `RCT_NEW_ACRH_ENABLED` even when the other method is used because we need to inject that flag into the codebase.
## Changelog
[iOS][Fixed] Make sure to turn on the `RCT_NEW_ACRH_ENABLED` flag
Reviewed By: cortinico
Differential Revision: D39430904
fbshipit-source-id: abb55642b4c72d7dec8b045fb4a43c1763f0ee0f
Summary:
Fix invalid range "t-5" in string transliteration [iOS] for M1 pod install issue.
This should fix pod install error for M1 machines.
## Changelog
[iOS] [Fixed] - Fix ios pod install error
Pull Request resolved: https://github.com/facebook/react-native/pull/34636
Test Plan: Run pod install on M1 machine.
Reviewed By: sammy-SC
Differential Revision: D39423276
Pulled By: cipolleschi
fbshipit-source-id: 4ec95af7103395792facba0f93fd8de05a3fe78d
Summary:
https://www.internalfb.com/T131530362
We are testing the New App template in CircleCI.
For Android we test the combination of Debug/Release and Old/New Architecture, and always use the Hermes engine.
We don't test the JSC engines (in iOS this is already happening).
We're not automatically testing that we can create a new project with JSC, forcing release managers to do it manually.
## Changelog
[Android] [Added] - Automatic testing of the new project template with the JSC engine.
Pull Request resolved: https://github.com/facebook/react-native/pull/34664
Test Plan:
- Open the circle-ci dashboard
- Verify there are now 8 jobs adeed to the pipeline:
```
test_android_template-Debug-Hermes-false
test_android_template-Debug-Hermes-true
test_android_template-Debug-JSC-false
test_android_template-Debug-JSC-true
test_android_template-Release-Hermes-false
test_android_template-Release-Hermes-true
test_android_template-Release-JSC-false
test_android_template-Release-JSC-true
```
- Verify they are all passing.
Reviewed By: cortinico
Differential Revision: D39426388
Pulled By: vincenzovitale
fbshipit-source-id: e5d606b1cc3ace53f8dab0f7d6d7d06ab11a2b46
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34619
When it comes to migrate existing libraries, users needs to update their .podspec files with a bunch [of changes](https://reactnative.dev/docs/0.69/new-architecture-library-ios#add-folly-and-other-dependencies).
This diff groups those changes in a single function, so that contributors can just invoke that function to prepare their dependencies.
## Changelog
[iOS][Changed] - Add function to simplify podspecs
Reviewed By: cortinico
Differential Revision: D39312203
fbshipit-source-id: ed631839e07d472a1fdcba33310f9b1d94fe2fd7
Summary:
Currently for codegen to work for a library on iOS, it needs to be located
inside `node_modules`. This patch adds support for libraries defined in
`react-native.config.js`.
This is useful when developing libraries as well as monorepos where the library
may exist outside of the `node_modules`.
Example:
```js
// react-native.config.js
const path = require('path');
module.exports = {
dependencies: {
'react-native-library-name': {
root: path.join(__dirname, '..'),
},
},
};
```
## Changelog
[Internal] [Added] - Support custom library paths in `react-native.config.js` for codegen on iOS
Pull Request resolved: https://github.com/facebook/react-native/pull/34580
Test Plan:
Tested on a test application and ensured that codegen finds the library specified in `react-native.config.js`
https://user-images.githubusercontent.com/1174278/188141056-bce03730-2a13-4648-8889-9727aaf2c3c4.mp4
I have also added a basic test case for this scenario.
Reviewed By: jacdebug, cortinico
Differential Revision: D39257919
Pulled By: cipolleschi
fbshipit-source-id: 131189f1941128a59b9b1e28af61a9038eb4536b
Summary:
This PR is the dual of the Matrix Tests we added to the Android Template a couple of weeks ago. It adds the same tests to iOS, to verify that the template builds with both architectures and with both configurations (Debug/Release).. And it tests that the template works with both Hermes and without it.
## Changelog
[iOS] [Added] - Test iOS template with both architectures and configurations
Pull Request resolved: https://github.com/facebook/react-native/pull/34469
Test Plan: CI is green in all the 8 new jobs.
Reviewed By: hramos, cortinico
Differential Revision: D39087876
Pulled By: cipolleschi
fbshipit-source-id: 1205b2339bac87cf11b4f356a2e50e1e93ba52bc
Summary:
The `sed` workaround here in `__apply_Xcode_12_5_M1_post_install_workaround`:
https://github.com/facebook/react-native/blob/main/scripts/react_native_pods.rb#L293-L298
does not work when the react native project has a parent folder with a space in the the name, for example:
`/Users/myuser/Some Folder/my-project/ios/Pods/RCT-Folly/folly/portability/Time.h`
This is because the `sed` command thinks that the part after the space is a separate argument.
This bug caused one of our engineers to not be able to run our React Native project through no fault of his own, so I would like to propose this change to help other engineers avoid this in the future.
## Changelog
Add single quotes around the file parameter in the `sed` command
[iOS] [Fixed] - Fixed Time.h:52:17: error when a folder in the file path has a space
Pull Request resolved: https://github.com/facebook/react-native/pull/34510
Test Plan:
Checkout the main branch.
Create a React Native project in a folder that has a space in the name.
When you run `pod install`, you should notice a `sed` error indicating that the text replacement failed.
Run the build to reproduce the `Time.h:52:17: error`.
Checkout this branch.
Run `pod install` and notice the `sed` error is gone.
Run the build, the error should be gone.
Reviewed By: sammy-SC
Differential Revision: D39082262
Pulled By: cipolleschi
fbshipit-source-id: 211099234edc6c9ee959bb61a760a6ca04a7a301
Summary:
Changelog:
[iOS][Fixed] - When source maps are enabled, clean up temporary files from the build directory. Reduces bundle size by at least 1MB.
Reviewed By: cipolleschi
Differential Revision: D38866158
fbshipit-source-id: 0f46faf4e767bb7417b24f283fbe19cfa022941a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34440
While testing some recent changes on a nightly, I realized that if we install the dependencies using RCT_NEW_ARCH_ENABLED=1 and we forget to change the flag in the Podfile, Fabric dependencies won't be installed.
However, Fabric is required by the New Architecture. This fix makes sure that we install Fabric dependencies when the New Architecture is enabled.
## Changelog
[iOS][Changed] Install Fabric dependencies when RCT_NEW_ARCH_ENABLED=1
Reviewed By: cortinico
Differential Revision: D38786978
fbshipit-source-id: 664151de0250577a19af949f8850e5efa8a13373
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34384
This Diff aims to create a RCTAppDelegate library to offer a subclass which automates some operations required to set up the new architecture.
## Changelog
[iOS][Added] - Added the RCTAppDelegate library
Reviewed By: cortinico
Differential Revision: D38580424
fbshipit-source-id: 38f6c4b8ff2790a2ce9e23d385b36307701cffb7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34398
This Diff cleans up the codegen folder for iOS when we install the pods. This is useful to start from a clean situation. The codegen runs after this step and we make sure that the file system is clean
## Changelog
[iOS][Changed] - Cleanup codegen build folder before installing the pods
Reviewed By: cortinico
Differential Revision: D38657027
fbshipit-source-id: 8a914457d7963521d6d8dc7819eba864736f50a0
Summary:
Sometime over the past few months (and with changes such as migrating to the `hermes-eslint` parser), a bunch of lint warnings crept into the codebase.
This does a pass to clean them all up, ignore generated files, and refactor some code to be... better.
There should be no observable behavior changes as a result of this.
Changelog:
[Internal]
Reviewed By: NickGerleman
Differential Revision: D38646643
fbshipit-source-id: a7b55d1e4cd5700340cc5c21f928baf3ea1d5a58
Summary:
This isolates and parallelize all the BUCK related work inside a `test_buck` job, so it's immediately clear where a failure happend.
I've also added a couple of minor improvements:
- Don't clone okbuck just to consume a script. I've copied the script over instead.
- Removed unnecessary `buck_cache_key`
This should reduce ~5 minute of build time from Test Android which was already beyond 10 minutes.
## Changelog
[Internal] - Isolate the buck OSS commands inside test_buck
Pull Request resolved: https://github.com/facebook/react-native/pull/34378
Test Plan: Let's wait for a `test_buck` and `test_android` output.
Reviewed By: cipolleschi
Differential Revision: D38580359
Pulled By: cortinico
fbshipit-source-id: 8b3915bbc28b4a7a169011fe9047f402c2d1f6ee
Summary:
Hermes is enabled by default. We set `USE_HERMES` envvar to `false` to explicilty disable Hermes. The only valid way to check it would be to compare it against `false`. Everything else will produce invalid results if `USE_HERMES` is not defined. For example `$USE_HERMES != true` will turn into `'' != true`, which evaluates to `true`.
Due to this bug source maps were not generated by default.
Changelog:
[iOS][Fixed] - USE_HERMES envvar check fixed in react-native-xcode.sh. Now source maps are generated by default.
Reviewed By: cipolleschi
Differential Revision: D38571971
fbshipit-source-id: bc6b505c225c56d62ee773b401b66d821965e106
Summary:
Fixed Flipper not recognizing app when using custom Xcode configuration names.
This fixes the problem that renaming the "Debug" Xcode configuration causes Flipper to not work. Despite using the recommended `:configurations` parameters and instructing Cocoapods that it was a debug build (see https://github.com/facebook/react-native/issues/34332), it still wouldn't recognize the app due to missing C preprocessor flags, specifically it was missing `-DFB_SONARKIT_ENABLED=1`.
## 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] [Fixed] - Flipper now supports custom Xcode build configuration names
Pull Request resolved: https://github.com/facebook/react-native/pull/34333
Test Plan:
I applied the PR change to 0.68.2 (which work similarly but code was refactored since then). I then used `patch-package` to test the change and the fix worked on 2 separate projects.
Patch-package change equivalent:
```diff
diff --git a/node_modules/react-native/scripts/react_native_pods.rb b/node_modules/react-native/scripts/react_native_pods.rb
index f2ceeda..2ea57d6 100644
--- a/node_modules/react-native/scripts/react_native_pods.rb
+++ b/node_modules/react-native/scripts/react_native_pods.rb
@@ -180,7 +180,7 @@ def flipper_post_install(installer)
# Enable flipper for React-Core Debug configuration
if target.name == 'React-Core'
target.build_configurations.each do |config|
- if config.name == 'Debug'
+ if config.debug?
config.build_settings['OTHER_CFLAGS'] = "$(inherited) -DFB_SONARKIT_ENABLED=1"
end
end
```
**Screen shot of Xcode after the patch has been applied, for RN v0.68.2:**
Reviewed By: dmitryrykun
Differential Revision: D38373812
Pulled By: cipolleschi
fbshipit-source-id: d2949927084160bf0c6f8af37a7966dd22fea9a6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34368
When a user runs `RCT_NEW_ARCH_ENABLED=1 pod install` to install the dependencies for the New Architecture, Cocoapods prints a warning because of React Native is still set up with a legacy configuration.
This diff silences these warnings because they can confuse the final user.
**Note:** We need to keep this legacy configuration to support both the legacy and the New Architecture.
## Changelog
[iOS][Changed] - Silence warning due to react-native internal details.
Reviewed By: cortinico
Differential Revision: D38503405
fbshipit-source-id: b89857aa88435b1c64da52875606003239ff2e05
Summary:
## Summary
Fixes https://github.com/facebook/react-native/issues/32497
Fixes https://github.com/facebook/react-native/issues/34212
The assigned HBC_SOURCEMAP_FILE path is incorrect as it does not reference the hermes bundle source map file
See: https://github.com/facebook/react-native/issues/32497#issuecomment-1171379674
## Changelog
[General] [Fixed] - using SOURCEMAP_FILE during xcode build phase with Hermes enabled
Pull Request resolved: https://github.com/facebook/react-native/pull/34111
Test Plan:
1. In a blank react-native project
1. Enable Hermes
1. Go to xCode -> Project -> Build Phases -> Bundle React Native code and images
3. Add `export SOURCEMAP_FILE="$(pwd)/../ios.jsbundle.map"` before `react-native-xcode.sh`
e.g.
```sh
export NODE_BINARY=node
export SOURCEMAP_FILE="$(pwd)/../ios.jsbundle.map"
../node_modules/react-native/scripts/react-native-xcode.sh
```
4. Make a release build `npx react-native run-ios --configuration Release` or `CMD + I` in xCode
5. Verify the build is successful
6. Verify the `.map` file is outputted at the specified path (`ios.jsbundle.map` in project root for the example above)
Reviewed By: cipolleschi
Differential Revision: D38460586
Pulled By: dmitryrykun
fbshipit-source-id: 54c1594b37fa2253896ce9739c1a9a712deecd0f
Summary:
The current `test-manual-e2e.sh` script is broken on Android + Hermes + New App Template.
This commit fixes it. Specifically:
- There is no need to generate Maven Artifacts for RN Tester, as RN Tester consumes them from source.
- There is instead a need to generate Maven Artifacts for New App Template, as they need to be included inside the NPM package.
- The `:ReactAndroid:hermes-engine:installArchives` task needs to invoked to also generate the Hermes-engine .aar for bundling.
## Changelog
[Internal] - Fix test-manual-e2e on Android/Hermes for New App Template
Pull Request resolved: https://github.com/facebook/react-native/pull/34294
Test Plan: I've tested this against the `0.70-stable` branch and I was able to run an App from the New Template properly.
Reviewed By: dmitryrykun
Differential Revision: D38239238
Pulled By: cortinico
fbshipit-source-id: b3d95bad21515b12a91e29147e70ba8323896660
Summary:
cherry-pick changes from https://github.com/facebook/react-native/issues/34214 to main. because the `react_native_pods.rb` on main is quite different from 0.69, i have separated pr for the change.
## Changelog
[iOS] [Fixed] - Fix React-bridging headers import not found
Pull Request resolved: https://github.com/facebook/react-native/pull/34271
Test Plan: RNTester + pod install and verify pod targets to have `React-bridging` in header search paths.
Reviewed By: cipolleschi
Differential Revision: D38122074
Pulled By: dmitryrykun
fbshipit-source-id: 64569abbfa3a684f0d6b84c9e3222bfc9a171061
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34232
This diff simplify the logic to decide whether we want to build hermes from source or not.
The requirement we have is that we don't want our users to build hermes.
So, we don't want to build hermes when there is a precompiled tarball available, while we want to build hermes in CI.
## Changelog
[General][Changed] - Build hermes when in CI and not when there is a tarball
Reviewed By: cortinico
Differential Revision: D37999748
fbshipit-source-id: 7d9cab51c37fb47db216055c057a22081e10df07
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34224
This Diff is a copy of this [PR](https://github.com/facebook/react-native/pull/34228) that we have against 0.69-stable.
This Diff makes sure we can build Hermes also in PR that are created against a stable branch
## Changelog
[General] [Changed] - Make sure we can build Hermes from source when PR are opened agains -stable
Reviewed By: cortinico
Differential Revision: D37961092
fbshipit-source-id: 65577fcc69f0e2a68377cbd46e3bd3a6af24e7c3
Summary:
This resolves issues where the node_modules structure is not hoisted (like with pnpm). Since the template does not directly depend on the cli, it doesn't exist in the pnpm node_modules root. Moving it to the rn scripts makes sure that the relative require starts in the correct directory for both hoisted and pnpm structures.
## Changelog
[iOS] [Fixed] - Fix cocoapods cli native_modules require for pnpm node_modules
Pull Request resolved: https://github.com/facebook/react-native/pull/34215
Test Plan:
1. react-native init
2. rm -rf node_modules
3. pnpm i
4. bundle install
5. bundle exec pod install --project-directory=ios
This should succeed. Without the patch, it will fail with
```
[!] Invalid `Podfile` file: cannot load such file -- /.../node_modules/react-native-community/cli-platform-ios/native_modules.
# from /.../ios/Podfile:2
# -------------------------------------------
# require_relative '../node_modules/react-native/scripts/react_native_pods'
> require_relative '../node_modules/react-native-community/cli-platform-ios/native_modules'
#
# -------------------------------------------
```
Reviewed By: cortinico
Differential Revision: D37959152
Pulled By: cipolleschi
fbshipit-source-id: 7fa9af4a8c153cfd38360f57eca415a8c252dbd5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34177
This Diff destructures the parameters of the use_react_native! function. It does that in a backward compatible way, so we there should be no disruptions.
It also adds documentation to the various public method we want to export to our users.
## Changelog
[iOS][Changed] - Destruct use_reactnative parameters and ad ddocumentation
Reviewed By: cortinico
Differential Revision: D37787365
fbshipit-source-id: 27f9030db2e8c6c66b9548b4c1287eb8165ae5fc
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34176
It extracts the code related to the codegen from the main `react_native_pods` script to a dedicated file, adding also tests.
## Changelog
[iOS][Changed] - Move codegen in separate files
Reviewed By: cortinico
Differential Revision: D37755818
fbshipit-source-id: 99760d1def26ddbf065fdd234e0d183c2795513c
Summary:
Automatically create a GitHub Release draft when a new React Native release is created.
The GitHub Release will be created by the same Circle CI job that publishes the package to npm.
This job will also upload the built Hermes binaries to the GitHub release.
Changelog: [Internal]
Reviewed By: cipolleschi
Differential Revision: D36646696
fbshipit-source-id: 0a863dc4e3215fc95f7852f8dc43858cdd852aaa
Summary:
Before this change, during the "Start Packager" Xcode build step that runs the packager, `packager.sh` was using my system node version and not the one from `nvm` that is meant to be used with the project.
## Changelog
[iOS] [Fixed] - Use `NODE_BINARY` from `.xcode.env` when running packager from Xcode
Pull Request resolved: https://github.com/facebook/react-native/pull/34121
Test Plan: Perform a build using Xcode and confirm that the packager is using the correct version of node.
Reviewed By: cortinico
Differential Revision: D37746951
Pulled By: cipolleschi
fbshipit-source-id: de697c27fe86ce65e8e3646cb30309ecc7f6c247
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34100
This Diff continue the effort of refactor and test the cocoapods script, moving hermes setup in a dedicated `hermes.rb` file and adding some tests on the logic of the hermes handling.
## Changelog
[iOS][Changed] - move and test Hermes setup from react_native_pods script into a dedicated file
Reviewed By: cortinico
Differential Revision: D37522432
fbshipit-source-id: 91112476aac576a30110e5dcd4e46fa12241962a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34142
The `||=` operator in an expression like `x = a ||= b` works in a way that:
- if a is null, it assigns b to x
- if a is `falsy`, it assigns b to x
- otherwise, it assigns a to x.
In our setup, if the user set `hermes_enabled` to `false` in the Podfile (one of the suggested way to disabled Hermes), the `options[:hermes_enabled]` part will evaluate to false and, therefore, `hermes_enabled` will obtain the value of `true`.
## Changelog
[iOS][Changed] - Use the correct operator to decide whether Hermes is enabled or not.
Reviewed By: cortinico
Differential Revision: D37643845
fbshipit-source-id: 387f7bd642250c40873400d22d7d85451462c073
Summary:
This PR adds a new method called **__apply_mac_catalyst_patches** to **scripts/react_native_pods.rb**. If it is enabled in the Podfile, it will apply three patches necessary for successful building not only for iOS and tvOS targets, but also for macOS using Apple's Mac Catalyst technology.
These 3 patches are:
- Fixing bundle signing issues by altering CODE_SIGN_IDENTITY
- Explicitly setting dead code stripping flag in project.pbxproj
- Modifying library search paths
The details were discussed here https://github.com/reactwg/react-native-releases/discussions/21#discussioncomment-2754289
## Changelog
[iOS] [Added] - Add Mac Catalyst compatibility (can be enabled in Podfile)
Pull Request resolved: https://github.com/facebook/react-native/pull/34026
Test Plan:
1. Go to project settings in Xcode, to General tab. Enable "iPad" and "Mac Catalyst" checkboxes
2. Go to "Signing & Capabilities" tab, ensure that a correct bundle id and development team are set
3. Edit Podfile, uncomment **__apply_mac_catalyst_patches(installer)** line
4. Run `pod install` in ios directory
5. Get back to Xcode, select "My Mac (Mac Catalyst)" as a target device
6. Build & run
Reviewed By: cipolleschi
Differential Revision: D37362054
Pulled By: cortinico
fbshipit-source-id: 74636f716f112289ab40968bbc8e52406c1e9579
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34085
Hermes is now the default engine on iOS.
Apps can choose to continue using JSC by setting `hermes_enabled` to `false` in their Podfile.
The RNTester app now uses Hermes, as well. Use JSC in RNTester by setting `USE_HERMES=0` when running `pod install`.
Changelog:
[iOS][Changed] Hermes is now the default engine on iOS. This setting is controlled via `flags[:hermes_enabled]` in the Podfile.
Reviewed By: cortinico, cipolleschi
Differential Revision: D37361468
fbshipit-source-id: e6dda6a23eea4a824ad157d1a26f17e181db33cd
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34025
This diff moves the monkeypatch LocalPodspecPatch to a dedicated ruby file.
It also adds test for that
## Changelog
[iOS][Changed] - Move LocalPodspecPatch to dedicated file
Reviewed By: cortinico
Differential Revision: D37069361
fbshipit-source-id: 28fddb197484f45aa20ccac516c874e79448e999
Summary:
This PR is a follow up for the contributing content move on the website:
* https://github.com/facebook/react-native-website/pull/3120
It replaces most of the CONTRIBUTING file content with a reference to the contributing overview page on the website, which has been based off the content of this file.
Additionally I have searched thought the code for the wiki links and replaces theme with the correct website links. There was an instance where comment was referring to an old and removed a while ago wiki page, so I just get rid of this link.
## Changelog
[Internal] [Chore] - Update CONTRIBUTING.md, replace wiki links
Pull Request resolved: https://github.com/facebook/react-native/pull/34035
Test Plan: N/A
Reviewed By: lunaleaps
Differential Revision: D37318814
Pulled By: cortinico
fbshipit-source-id: d3f5e5c5bd477c0de5c4f0f1d5de81f464b9f5b4
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:
`use_frameworks!` is broken again in react-native 0.69 because React-bridging. in the `use_frameworks!` mode, header structures are flattened, so `#include <react/bridging/CallbackWrapper.h>` is not reachable to the header. to somehow workaround the issue without touch React-bridging imports, the pr do these things:
- use `header_mappings_dir` to keep `react/bridging` header structure
- because the header structure is not default framework header structure, explicitly `HEADER_SEARCH_PATHS` is necessary.
- forward declare `CallbackWrapper` and use it internally in ReactCommon. so that we don't need to add `HEADER_SEARCH_PATHS` for React-bridging to every pods depending on `ReactCommon/turbomodule/core`, e.g. React-RCTSettings.podspec.
## Changelog
[iOS] [Fixed] - Fix use_frameworks! for 0.69
Pull Request resolved: https://github.com/facebook/react-native/pull/34011
Test Plan:
```sh
$ npx react-native init RN069 --version next
# add `use_frameworks!` to ios/Podsfile
# comment out use_flipper!() in ios/Podfile
# patch node_modules/react-native with these changes
$ yarn ios
```
Reviewed By: cortinico, cipolleschi
Differential Revision: D37169699
Pulled By: dmitryrykun
fbshipit-source-id: 309c55f1c611a2fc3902a83e8af814daaf2af6a0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/33990
This diff moves the setting of some CPP flags from the main React native pods file to a dedicated file.
It also introduces some tests and it improves the Test Mocks we have
## Changelog
[iOS][Changed] - Move the `modify_flags_for_new_architecture` method to separate ruby file
Reviewed By: cortinico
Differential Revision: D37040927
fbshipit-source-id: 037ddaf123d01f3a2fd622b8a0cd10535da70b92
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/33982
This Diff moves another part of the utilities from the `react_native_pods` file to a specific `utils.rb` file.
It adds tests for these utils and improve our test mocks.
The goal is to simplify the `react_native_pods.rb` so it's easier to work with it.
I decided to split this diff in 2 because it was becoming quite big.
## Changelog
[iOS][Changed] - Refactoring part of the react_native_pods.rb script
Reviewed By: cortinico
Differential Revision: D37006265
fbshipit-source-id: ffaac3270cb098fa30b73c97ce7cd350dfb8d7d6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/33978
This Diff moves part of the utilities from the `react_native_pods` file to a specific `utils.rb` file.
It adds tests for these utils and improve our test mocks.
The goal is to simplify the `react_native_pods.rb` so it's easier to work with it.
I decided to split this diff in 2 because it was becoming quite big.
## Changelog
[iOS][Changed] - Refactoring part of the react_native_pods.rb script
Reviewed By: cortinico
Differential Revision: D37004347
fbshipit-source-id: a5156f7c199d082d5d895a58af80948556c51c2a
Summary:
Reverts https://github.com/facebook/react-native/pull/29012
It is not really possible to properly validate if ENTRY_FILE exists since it is resolved by metro, and the server is not always running from the app root, like in a monorepo with multiple RN apps running on the same metro server.
In my case I run metro on the repo root and entry file will be something like `apps/app/index.js`. `-f "$ENTRY_FILE"` will fail since the script is run from the project folder (`PROJECT_ROOT`, in my case the `apps/app` folder, so it tries to resolve `apps/app/apps/app/index.js`).
I don't think this check is actually useful since metro will report the error if the entry file is invalid (fixed in https://github.com/facebook/react-native/pull/30150). The error is not as user friendly, but I think it is still fine. Maybe it could be improved in metro.
## Changelog
[iOS] [Fixed] - Don't validate ENTRY_FILE in react-native-xcode.sh
Pull Request resolved: https://github.com/facebook/react-native/pull/32762
Test Plan:
Before
<img width="854" alt="image" src="https://user-images.githubusercontent.com/2677334/146100834-39310c9f-1767-496a-8698-1026726a1120.png">
After if file is actually missing
<img width="987" alt="image" src="https://user-images.githubusercontent.com/2677334/146100893-d01e2247-c787-4174-ac60-2f308c338c8f.png">
After if file exists, builds successfully.
Reviewed By: cortinico
Differential Revision: D37066073
Pulled By: cipolleschi
fbshipit-source-id: 8f6b149099a39d9179996bb965daa6cd9e06feac
Summary:
Allow an arbitrary path to hermes-runtime-darwin-vX.Y.Z.tgz to be specified. This can be used in CI or in local e2e tests to test with Hermes enabled without having a matching GitHub release.
Usage:
```
HERMES_ENGINE_TARBALL_PATH=~/Downloads/hermes- runtime-darwin-v0.69.0.tar.gz \
USE_HERMES=1 \
pod install
```
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D36985477
fbshipit-source-id: 853829c89e6f0ac3f63781c7f290cf3994b8e0cd
Christoph Purrer
Dmitry Rykun
Héctor Ramos
Pranav Yadav
Nick Gerleman
Lorenzo Sciandra
Riccardo Cipolleschi
Nicola Corti
Donald Webster
Paige Sun
Kudo Chien
Krystof Woldrich
Tim Yung
Nicola Corti
Vincenzo Vitale
Riccardo Cipolleschi
fortmarek
Nenad Vojnovic
Luna Wei
Rujin Cao
Roman Melnyk
Satyajit Sahoo
Gabriel Rogan
Dmitry Rykun
Tim Yung
Seph Soliman
Peter Velkov
LeoTM
Dmitry Minkovsky
Danilo Bürger
Héctor Ramos
Ernest Surudo
Ben
Arkkeeper
Simek
Luis Santana
Alpha Shuro
Janic Duplessis
