Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35521
Inside RC3 the jscexecutor target was prepared for prefab consumption
but not properly exposed.
This was not caught by the CI as we're not effectively using this target,
but some of our popular libraries do (i.e. Reanimated). I'm exposing it here.
Changelog:
[Internal] [Changed] - Properly expose `jscexecutor` as a prefab target
Reviewed By: javache
Differential Revision: D41648349
fbshipit-source-id: 1a04bc21aa50eece304828ce1d99ae795a51af48
* [LOCAL] fix: use META_CI instead of CI envvar
* META_CI -> REACT_NATIVE_CI
* Rename more occurences of CI to REACT_NATIVE_CI
* Use REACT_NATIVE_CI in rn-tester/Podfile
* Add REACT_NATIVE_CI to prepare_hermes_workspace
* revert: Use REACT_NATIVE_CI in rn-tester/Podfile
* Consume hermes-engine.podspec from sdks/hermes-engine
* Consume hermes-engine.podspec from sdks/hermes-engine. Update tests
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35497
In 0.71.0-RC.2, we had a regression in `use_frameworks!`.
This adds some CircleCI jobs to make sure we do not regress on those. It also updates the template to support these tests.
## Changelog
[iOS][Added] - CircleCI jobs to keep the use_framework! setup in check for the Old Arch
Reviewed By: cortinico
Differential Revision: D41551288
fbshipit-source-id: 531fabb1a7b6aceab2926bb83cf2887129df1776
Summary:
In 0.71.0-RC.2, we had a regression in `use_frameworks!`.
This brings back JSIDynamic and JSI together because the current setup is not compatible with iOS frameworks
## Changelog
[iOS][Added] - Bring back JSIDynamic and JSI
Reviewed By: cortinico
Differential Revision: D41557823
fbshipit-source-id: 95eb2fe7df69992861396e41d11cd5182193e1a3
# Conflicts:
# ReactCommon/jsi/React-jsidynamic.podspec
Summary:
In 0.71.0-RC.2, we had a regression in `use_frameworks!`.
The `use_frameworks! :linkage => :static` use to work fine with the Old Architecture.
We modified how the `React-bridging` pod is configured and, now those are broken.
This change make sure to use the right imports for React-bridging.
## Changelog
[iOS][Changed] - Fix imports in React Bridging for Old Arch and frameworks
Reviewed By: christophpurrer, cortinico
Differential Revision: D41551103
fbshipit-source-id: 4416fde92fef11eb801daf2302a57fe52732e4ef
Summary:
This change excludes the `LongLivedObject.h` file from the pod in the ReactCommon library.
The file creates a problem when the `use_frameworks!` option is used in an app because there can't be two files with the same name, despite being in different paths,
within the same framework. Specifically, this `LongLivedObject` is just a redirect to the other one, so it should be safe to exclude this.
## Changelog
[iOS][Fixed] - Exclude redirector to `LongLivedObject.h` from ReactCommon podspec
Pull Request resolved: https://github.com/facebook/react-native/pull/35491
Test Plan: 1. Manually tested in an app from RC2
Reviewed By: cortinico
Differential Revision: D41548985
Pulled By: cipolleschi
fbshipit-source-id: acc57fccdedb344a3aa105f2968645a049392e07
Summary:
See the issue at https://github.com/facebook/react-native/issues/32432#issuecomment-1242234121
This fixes a bizarre issue when using the GNU coreutils tools. There are very minor differences in the standard command-line tools on macOS and the GNU coreutils. The `cp` command has slightly different semantics across these operating systems, so this commit normalizes those differences and allows GNU coreutils to be used or the system native version of `cp`.
Fixes#32432
## Changelog
[General] [Fixed] - Allow GNU coreutils to be used to build projects
Pull Request resolved: https://github.com/facebook/react-native/pull/35382
Test Plan: This change allows the use of the system or GNU coreutils verson of `cp`.
Reviewed By: cipolleschi
Differential Revision: D41532472
Pulled By: cortinico
fbshipit-source-id: f0fe5274d3828bf6099deceee797a82a6adfdcab
Summary:
This PR updates the Cache strategy for the tarballs to include the React Native version we are building. In this way, when we publish a new Release/RC we are sure that we are going to rebuild a nmew
tarball. This should fix caching problems like:
- we have misconfigured the build script for the Hermes tarball, we then fix it, but we distribute the wrong cached artifacts
- the cached artifact has the wrong version
## Changelog
[Internal] - Fixed Hermes Tarball Cache Logic
Pull Request resolved: https://github.com/facebook/react-native/pull/35471
Test Plan:
1. CircleCI
The real way to check this is in the next RC cycle or in the next nightly.
Reviewed By: cortinico
Differential Revision: D41530651
Pulled By: cipolleschi
fbshipit-source-id: 45e8fd3b62c8e108d393d9463ff6762dfc6d3ec8
Summary:
Fixes https://github.com/facebook/react-native/issues/35429
This fix is fairly straightforward. Instead of hardcoding two separate paths for this repo or a simple user's project, we ask Node to resolve `react-native-codegen`.
Because `react-native-codegen` is moved [into the `/packages/*` folder](https://github.com/facebook/react-native/blob/main/package.json#L104), it's part of a workspace in this repository. That means that this fix works not only for monorepos in general but also resolves the right path within the react native repository.
You can test this out yourself when running this command in either the root, or any other workspace in this repository:
```bash
node --print "require('path').dirname(require.resolve('react-native-codegen/package.json'))"
```
I've tested this on Node 16 and 18, and seems to work nicely. Note that you _**have to specify `react-native-codegen/package.json`**_. That's because the `react-native-codegen` package itself is technically invalid; it's missing an entry point within the package (no `main`). When running `node --print "require.resolve('react-native-codegen')"` Node can't resolve the main entry point, and will fail during this process.
## 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] - Fix incorrect codegen CLI paths in monorepo projects
Pull Request resolved: https://github.com/facebook/react-native/pull/35430
Test Plan: See PR https://github.com/facebook/react-native/issues/35429
Reviewed By: cortinico
Differential Revision: D41475878
Pulled By: cipolleschi
fbshipit-source-id: f0c362b64cf9c3543a3a031d7eaf302c1314e3f0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35508
It turns out that my previous diff hasn't really solved the Windows support.
The problem is that we're not escaping the URI of the Maven Local repository
properly on Windows.
To overcome this, I'll instead use the `toURI()` Api of File to properly
create a valid URI for a given folder.
Changelog:
[Internal] [Changed] - RNGP - Fix DependencyUtils for Windows support
Reviewed By: cipolleschi
Differential Revision: D41581849
fbshipit-source-id: 7905073c6daaf7c6a97405b3e6fb94b8f382234a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35506
In our build we had a mixture of `_` and `-` to separate targets.
Dashes don't play well with Gradle + as we expose them now via Prefab,
let's stick to use only underscores
Changelog:
[Internal] [Changed] - Rename target to don't use dashes
Reviewed By: cipolleschi
Differential Revision: D41578938
fbshipit-source-id: 8aa44aa2dc7bf4822b45e5044532837b989817d2
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35496
This commit includes a series of fixes needed for better integration with libraries for 0.71:
- I've added an `android/README.md` file as some libraries were failing the build if the folder was missing
- RNGP now applies dep substitution on app and all the libraries project
- RNGP now adds repositories on app and all the libraries project
- I've removed the maven local repo to the `/android` folder as now is empty
- I've fixed the path for the JSC repo for Windows users
- I've added a bit of backward compat by re-adding an empty `project.react.ext` block that libraries might read from.
- I've removed `codegenDir` from the `GenerateCodegenArtifactsTask` which was unused.
Changelog:
[Internal] [Changed] - RNGP - Various improvements needed for 3rd party libs
Reviewed By: cipolleschi
Differential Revision: D41549489
fbshipit-source-id: 2252da0180ac24fd3fe5a55300527da6781f0f8c
Summary:
This is the last library that we should expose via Prefab.
Thanks to cipolleschi 's work here moving the file to `/ReactCommon/jsc` folder
we can easily expose it to be consumed by third parties.
Changelog:
[Internal] [Changed] - Expose `jscruntime` to be consumed via Prefab
Reviewed By: cipolleschi
Differential Revision: D41534564
fbshipit-source-id: fb4b2d801def8caf71638dcb74eb87f8230984d4
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35482
This change moves the JSCRuntime.h/cpp into a `jsc` folder.
This change is required for several reasons:
1. on iOS, the new `jsi`, `jsidynamic` and `jsc` setup is breaking the `use_frameworks!` with `:linkage => :static` option with the old architecture. So it is a regression.
2. JSCRuntime is required by some libraries and needs to be exposed as a prefab and the current setup makes it hard to achieve.
allow-large-files
[General][Changed] - Move JSCRuntime into a separate pod/prefab
Reviewed By: cortinico
Differential Revision: D41533778
fbshipit-source-id: 642240c93a6c124280430d4f196049cb67cb130b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35456Fixes#35439
There is a bug in AGP 7.3.x which is causing assets to don't be copied properly inside the
final artifact: issuetracker.google.com/issues/237421684
As AGP 7.4.x is really close to release (is in Beta5, should be released stable in the next weeks)
we should be fine by bumping to beta5.
This also requires a bump of RNGP
Changelog:
[Android] [Changed] - Bump AGP to 7.4.x
allow-large-files
Reviewed By: cipolleschi
Differential Revision: D41519549
fbshipit-source-id: 60d568a3e49798a23f1d7bf4839ab58bd5549aba
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35461
This is another library which is adding prefab support as it's needed by
Expo libraries and Reanimated.
Changelog:
[Internal] [Changed] - Allow `reactnativejni` to be consumed via prefab
Reviewed By: cipolleschi
Differential Revision: D41520801
fbshipit-source-id: 91142a5b5051cfba478d93a2475a178eed6fbb29
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35460
Reanimated reported that `react_nativemodule_core` was missing some headers.
Specifically the one from ReactAndroid::react_debug, ReactAndroid::react_render_core, ReactAndroid::glog,
and ReactAndroid::react_render_debug.
I'm adding them here so they get included in the shipped headers for `react_nativemodule_core`
Changelog:
[Internal] [Changed] - Add missing headers to `react_nativemodule_core` prefab module
Reviewed By: cipolleschi
Differential Revision: D41520751
fbshipit-source-id: 4627a2d0f880d4bb3ff2f0e43cd735cf9a3f2f9a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35458
We're adding prefab support for those modules as they're needed by Reanimated
and we're exposing headers for them as well.
Changelog:
[Internal] [Changed] - Add prefab for _uimanager _scheduler and _mounting
Reviewed By: cipolleschi
Differential Revision: D41520606
fbshipit-source-id: 76f3c81705e99057b92cd9b86d0601a2b1410f95
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35457
This exposes `hermes-executor` to be consumed via prefab so that
libraries can depend on it and use its symbols if needed (Expo and Reanimated need it).
Changelog:
[Internal] [Changed] - Expose `hermes-executor` to be consumed via prefab
Reviewed By: cipolleschi
Differential Revision: D41520019
fbshipit-source-id: d590a043ea89fdd8ff41b0ed20900c9cf381a1e4
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35454
Historically, we used to have hermes-executor debug and release as separate dynamic libraries.
This makes it impossible to prefab this library, so I have to reconcile it into a single library.
This will also help keep the setup consistent with the internal (BUCK) where we have a single target.
Changelog:
[Internal] [Changed] - Consolidate hermes-executor-debug and -release inside a single target
Reviewed By: cipolleschi
Differential Revision: D41519119
fbshipit-source-id: d9ddc30b72164daa29c735836ea433fd4d917fc8
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35455
This little change allows to support Gradle Configuration cache in user projects:
https://docs.gradle.org/current/userguide/configuration_cache.html
It allows to save several seconds on the build time.
We'll keep it disabled for now, but Gradle plans to enable it by default for everyone
in the future, so this changes makes us ready for it.
Changelog:
[Internal] [Changed] - RNGP - Correctly Support Gradle Configuration Cache
Reviewed By: cipolleschi
Differential Revision: D41519506
fbshipit-source-id: 6252546e811deb0777c0aab5332291368be7fa8f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35397
This Diff removes the `HERMES_BUILD_FROM_SOURCE` that was not always propagated to the original script. This lead to some cases where hermesC was built during `pod install` and then removed by the `react_native_post_install`'s `else` branch.
Basically, when the Pods are installed the first time, everything run smoothly. Subsequent invocations of `pod install`, to install other dependencies, for example, will incur in this problem because:
1. Cocoapods will see that hermes-engine is already installed
2. the podspec is not executed, given that the pod has been fetched from the cache
3. The env var is not set (given that the podspec is not executed)
4. the main script sees the env var as not set, `ENV['HERMES_BUILD_FROM_SOURCE'] == "1"` return false
5. The `else` branch is executed, and it removes the `hermesc_build_dir` and the `copy Hermes framework` script phase.
[iOS][Changed] - Remove `HERMES_BUILD_FROM_SOURCE` flag
Reviewed By: cortinico, dmytrorykun
Differential Revision: D41373439
fbshipit-source-id: ea4aafd187c0ca3ff5c0d79f8aeaaa46ad50f499
Summary:
This is a backport of [this](https://github.com/facebook/react-native/commit/becb47ccb6a6ed77e81b5488561ef6d683933ffe) local fix we made on
0.71-stable.
All our podspecs delegates to the main React Native pods script to set up the dependencies properly. The React-Codegen.podspec, which is generated by
the script itself, was generated with hardcoded dependencies. This PR aligns the versioning with the other podspec.
On a side note, this could create issues in CI and when releaseing, because we are changing the versions to prepare the new release and it breaks some
steps.
## Changelog
[iOS] [Fixed] - Make sure that the React-Codegen.podspec does not enforce specific versions of its dependencies.
Pull Request resolved: https://github.com/facebook/react-native/pull/35274
Test Plan:
1. Ruby tests are passing
2. Manually tested that pods are correctly installed in the following configurations
- RNTester - Hermes - Old Architecture
- RNTester - Hermes - New Architecture
- RNTester - JSC - Old Architecture
- RNTester - JSC - New Architecture
Reviewed By: christophpurrer
Differential Revision: D41153859
Pulled By: cipolleschi
fbshipit-source-id: 043513866a66ecca3e326f8671bea3ec576422de
# Conflicts:
# scripts/cocoapods/codegen_utils.rb
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35296
This change adds some version checks and enforces that every version matches some specific format based on the build type we are trying to run.
## Changelog
[General][Changed] - Improve version checks
Reviewed By: cortinico
Differential Revision: D41161756
fbshipit-source-id: 4172195c5e031c1eaf7b33bb74f381c04e9adaf5
Summary:
This PR makes sure that the `preapre_package_for_release` script fail fast if there is already a tag for the desired version
on github.
## Changelog
[General] [Added] - Make the `prepare_package_for_release` fail if there is already a git tag with that version
Pull Request resolved: https://github.com/facebook/react-native/pull/35305
Test Plan:
Tested manually. The script is currently only invoked during the release process.
<img width="1238" alt="Screenshot 2022-11-10 at 12 24 03" src="https://user-images.githubusercontent.com/11162307/201090947-274c1b1c-0b6a-4619-bc85-fa60e5eaeee1.png">
Reviewed By: cortinico
Differential Revision: D41403159
Pulled By: cipolleschi
fbshipit-source-id: fb87df345b14568c750482e5c68be53551a9acbb
# Conflicts:
# scripts/release-utils.js
Summary:
Original title: **[RN] Do not encode path to cmake in hermes-engine Pod, build hermesc in prepare_pods**
The result of `#{%x(command -v cmake | tr -d '\n')}` was being encoded into the `hermes-engine` Pod. This can lead to conflicts in the CocoaPods cache when `pod install` is run on different machines.
Instead of running the command during `pod install`, we defer to the actual build scripts so they can find `cmake` when `$CMAKE_BINARY` is not set.
More importantly, this fixes an issue that crept into the Sandcastle CocoaPods offline mirrors, but which would only manifest itself when people run `js1 oss prepare-pods`.
RNTester would not build due to RNTesterPods.xcworkspace being configured to use cmake from an arbitrary path instead of using the cmake from $PATH.
This does not affect Sandcastle due to `CMAKE_BINARY` getting overriden in Sandcastle.
---
**Update** by dmytrorykun:
It is impossible to address the problem described in the original title by simply adding `CMAKE_BINARY=${CMAKE_BINARY:-cmake}` to `build-hermes-xcode.sh`. This script is supposed to run from Xcode. Since Xcode doesn't have access to system `PATH` variable, it is unable to locate `cmake`, and build fails.
However this diff contains other useful changes:
1. Remove trailing newline in `cmake` path in `build-hermes-xcode.sh`.
2. Fix inverted logic in `copy-hermes-xcode.sh`.
3. Fix typo in `remove xcuserdata` step in Sandcastle.
4. Remove unused `HERMES_DISABLE_HERMESC_BUILD`.
Changelog:
[iOS] [Fixed] - Various fixes for Hermes build-from-source behaviour.
Reviewed By: cipolleschi
Differential Revision: D41139384
fbshipit-source-id: 4a4a44a7ac201d279718d84cd02d60b4eaf3956b
Nicola Corti
Riccardo
Dmytro Rykun
Distiller
Lorenzo Sciandra
Riccardo Cipolleschi
Steve Shreeve
Cedric van Putten
Simen Bekkhus
Lorenzo Sciandra
Distiller
Dmitry Rykun
Distiller
