Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35212
A previous change - https://github.com/facebook/react-native/pull/34011 - already fixed basic usage of <react/bridging/.../ imports.
However that change was only tailored towards the usage of: <react/bridging/CallbackWrapper.h>
Any other header besides <react/bridging/CallbackWrapper.h> from <react/bridging/... can't be imported at this time in Xcode ... ... which is bad.
For C++ TurboModules we need to be able to access *any* <react/bridging/...> header via the React-Codegen CocoaPod.
Hence adding bridging now as a sub-spec to the ReactCommon CocoaPod
Changelog: [Internal]
Reviewed By: cipolleschi
Differential Revision: D41057878
fbshipit-source-id: 83c117bc5252d84dd419cdb72f145f65547d23b2
# Conflicts:
# scripts/cocoapods/__tests__/codegen_utils-test.rb
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 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
Oleksandr Melnykov
Christoph Purrer
Nicola Corti
Lorenzo Sciandra
Riccardo Cipolleschi
Nick Gerleman
Héctor Ramos
Dmitry Rykun
Riccardo Cipolleschi
Donald Webster
Paige Sun
Kudo Chien
Krystof Woldrich
Tim Yung
Nicola Corti
Vincenzo Vitale
