Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35619
Reference https://github.com/reactwg/react-native-releases/discussions/41#discussioncomment-4353534
I'm exposing `ReactAndroid/src/main/jni/react/cxxcomponents` to be consumed via prefab.
It will be available to both: `react_nativemodule_core` and `reactnativejni`
Changelog:
[Internal] [Changed] - Expose ReactAndroid/src/main/jni/react/cxxcomponents via prefab
Reviewed By: cipolleschi
Differential Revision: D41965512
fbshipit-source-id: 3a5a7473267e2e161d9d7fb0e8dfa74593b47b6e
Summary:
After adding `<uses-permission android:name="android.permission.POST_NOTIFICATIONS"/>` on my `AndroidManifest.xml`, I expected to use `PermissionsAndroid.PERMISSIONS.POST_NOTIFICATIONS` but `POST_NOTIFICATIONS` is `undefined` and is named `POST_NOTIFICATION` instead.
Every other Android permission is 1:1 in spelling except this one where it lacks `S`.
Not sure if this is a welcome change since this can be breaking. Or maybe we can include both with and without `S` to not be a breaking change. Or just keep it as is and close this PR.
## 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
-->
[Android] [Changed] - Rename `POST_NOTIFICATION` to `POST_NOTIFICATIONS`
Pull Request resolved: https://github.com/facebook/react-native/pull/35533
Test Plan: `PermissionsAndroid.PERMISSIONS.POST_NOTIFICATIONS` should not be `undefined`.
Reviewed By: cortinico
Differential Revision: D41705866
Pulled By: philIip
fbshipit-source-id: a0328b174f0196421565f0cd2b2f1eb509428553
# Conflicts:
# packages/rn-tester/js/examples/PermissionsAndroid/PermissionsExample.js
Summary:
Encountered this, causing typechecking to fail on an example in the current RN documentation.
`onFail` is an optional parameter (see https://github.com/facebook/react/blob/8e2bde6f2751aa6335f3cef488c05c3ea08e074a/packages/react-native-renderer/src/ReactNativeTypes.js#L106), which is not optional in current TS types. Update the TS typings to match.
Note that "?" here is positioned to be a Flow optional parameter, instead of a maybe type. Which means it accepts undefined, but not null, matching the TS usage of "?" which always means possibly undefined (but never null, like a flow maybe type allows).
Changelog:
[General][Fixed] - Fix TS Type for measureLayout optional parameter
Reviewed By: lunaleaps
Differential Revision: D41775900
fbshipit-source-id: 8f53428b8077ec9139c7c1bbc60ed20f5fa9f7ea
Summary:
Small PR with bump to the new versions of CLI and Metro in preparation of the stable release for 0.71.
## Changelog
[General] [Changed] - Bump CLI to 10.0.0 and Metro to 0.73.5
Pull Request resolved: https://github.com/facebook/react-native/pull/35580
Test Plan: CI green
Reviewed By: cortinico
Differential Revision: D41800580
Pulled By: jacdebug
fbshipit-source-id: 7bf81308eb41490b004e685b1763574bfd3b27fb
# Conflicts:
# package.json
# yarn.lock
Summary:
`findPackageJsonFile` always returns a path even though `package.json` does not exist. This causes issues in libraries whose repo setups look like:
```
react-native-webview
├── android
│ └── build.gradle
├── example <-- Note the lack of `package.json` here
│ └── App.tsx
├── ios
│ └── RNCWebView.xcodeproj
├── macos
│ └── RNCWebView.xcodeproj
├── package.json
└── src
```
When `newArchEnabled=true`, running `yarn android` will fail with the following:
```
FAILURE: Build failed with an exception.
* What went wrong:
Could not determine the dependencies of task ':app:generateCodegenArtifactsFromSchema'.
> Could not create task ':app:generateCodegenSchemaFromJavaScript'.
> /~/react-native-webview/example/package.json (No such file or directory)
```
## Changelog
[Android] [Fixed] - `findPackageJsonFile` should return `null` if `package.json` does not exist
Pull Request resolved: https://github.com/facebook/react-native/pull/35566
Test Plan:
```
git clone https://github.com/react-native-webview/react-native-webview.git
cd react-native-webview
git checkout new-arch-ios
yarn
cd example/android
./gradlew clean assembleDebug
```
Reviewed By: NickGerleman
Differential Revision: D41739176
Pulled By: cortinico
fbshipit-source-id: cab0f1f717db160df244c9bb2769e345d6e19917
Summary:
Revert the template `Podfile` to using `react-native-community/cli-platform-ios/native_modules`. The new internal script currently has a hard-coded path to `react-native-community/cli-platform-ios` which may not work in monorepos. The path in the `Podfile` is also hard-coded, but this is a file that the user has access to and can fix themselves if necessary.
## Changelog
[iOS] [Fixed] - Don't use the internal `native_modules.rb` script yet, as it hides a hard-coded path
Pull Request resolved: https://github.com/facebook/react-native/pull/35531
Test Plan: n/a
Reviewed By: rshest
Differential Revision: D41682119
Pulled By: cortinico
fbshipit-source-id: 1822fcd20a794dc9df6e8d6f36615e90b42c1a94
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35529
ESLint configuration is derived from `react-native/eslint-config`, which has supported Flow, vanilla JS, and TypeScript.
https://github.com/react-native-community/react-native-template-typescript/pull/238 and a related PR ended up adding new rules to the TypeScript config, to fix bugs with TS linting. It required a followup change, to specify the parser/plugin, and explicity reference them as devDependencies. https://github.com/react-native-community/react-native-template-typescript/pull/240
`react-native/eslint-config` already includes setting the plugin/parser. But overriding rules requires declaring that again, and directly referencing a plugin means a need for the app to declare dependencies, since ESLint resolves modules from the current config.
The rules overridedn were later fixed in `react-native/eslint-config`, which is really the right place for the fix (e.g. https://github.com/facebook/react-native/pull/32644). I noticed this when deriving from the TS template in https://github.com/facebook/react-native/pull/32644 and removed the rule overrides, but didn't have the historical context to realize this means we can then:
1. Remove the explicit parser/plugins since `react-native/eslint-config` already sets them, and we are no longer overriding any rules.
2. Remove the devDependencies, to let the versions be managed entirely by `react-native/eslint-config`.
Changelog:
[General][Changed] - Simplify Template ESLint Configuration
Reviewed By: cortinico
Differential Revision: D41652699
fbshipit-source-id: 8e3313dbf27407c5866f3c2432cffc2ecec1b01d
# Conflicts:
# template/_eslintrc.js
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
Distiller
Riccardo Cipolleschi
Nicola Corti
David Angulo
Nick Gerleman
Michał Pierzchała
Tommy Nguyen
Tim Yung
Dmytro Rykun
Distiller
Lorenzo Sciandra
Riccardo Cipolleschi
Steve Shreeve
Cedric van Putten
Simen Bekkhus
Lorenzo Sciandra
Distiller
Dmitry Rykun
Distiller