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 https://github.com/facebook/react-native/commit/1546666a6d713ef756b2f11de9581e3b2bbe08dc 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: https://github.com/facebook/react-native/commit/4b512077354eb4702ce144e9958d7513c1607275
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](https://github.com/facebook/react-native/commit/7680bdeb4f96a8092393372a59c77a9d7b729cae)) 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](https://github.com/facebook/react-native/commit/7680bdeb4f96a8092393372a59c77a9d7b729cae) 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 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/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
Héctor Ramos
Lorenzo Sciandra
Dmitry Rykun
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
