Summary:
Flipper-DoubleConversion and Flipper-Glog iOS pods received a build optimization
a few versions back that pre-compiled the pods and references the xcframework slices
Unfortunately, the pre-compile did not include macCatalyst slices, so this disabled support
for flipper on macOS for react-native >0.65
lblasa has re-compiled the pods with the macCatalyst slices added
See https://github.com/facebook/flipper/issues/3117
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://github.com/facebook/react-native/wiki/Changelog
-->
[iOS] [Fixed] - update Flipper pods to support re-enable macCatalyst
Pull Request resolved: https://github.com/facebook/react-native/pull/33406
Test Plan:
- [ ] The Flipper repo has a react-native test that appeared to work with these versions, CI should work here
- [ ] Prove there is no regression, a flipper-enabled build test should work for simulator iOS target on arm64
- [ ] Prove there is no regression, a flipper-enabled build test should work for simulator iOS target on x86_64 mac
- [ ] Prove there is no regression, a flipper-enabled build test should work for real device iOS target
- [ ] To prove the issue is resolved, a build should be attempted for a macCatalyst target, and it should work.
Reviewed By: cortinico
Differential Revision: D34789654
Pulled By: lblasa
fbshipit-source-id: 466803dd07b5820220512b7d7d760b94b8aa65f7
Summary:
Avoid breaking tools relying on absolute path for `cliPath`
## Changelog
[Android] [Fixed] - Enable cliPath to have an absolute path value
Pull Request resolved: https://github.com/facebook/react-native/pull/32983
Test Plan:
declare `cliPath` from `expo`:
```groovy
cliPath: new File(["node", "--print", "require.resolve('react-native/package.json')"].execute(null, rootDir).text.trim()).getParentFile().getAbsolutePath() + "/cli.js",
```
and run an android build
Reviewed By: ShikaSD
Differential Revision: D33843275
Pulled By: cortinico
fbshipit-source-id: 65f55a5e07a4ec0a6205d5f06f150377708c30cc
Summary:
alternative solution for https://github.com/facebook/react-native/issues/33379
> when `use_frameworks!` is on, there are errors like:
> ```
> 'FBReactNativeSpec/FBReactNativeSpec.h' file not found
> #import <FBReactNativeSpec/FBReactNativeSpec.h>
> ```
> this error may come from from https://github.com/facebook/react-native/commit/f7e4c07c84b6 regression.
>
> when `use_frameworks!` is on, xcode will search headers from framework directories, the correct imports would be `#import <React_Codegen/FBReactNativeSpec/FBReactNativeSpec.h>` (xcode will transform dash to underscore, so it is `React_Codegen` but not `React-Codegen`). in the other hand, when `use_frameworks!` is off, the correct import is `#import <React-Codegen/FBReactNativeSpec/FBReactNativeSpec.h>`.
>
>
> this fix is specific for old architecture (fabric is off).
>
> when fabric is on, there are other errors from duplicated headers when copying to build folder. [the reason is that framework build would try to flatten headers](https://mkonrad.net/2015/03/29/xcode-static-libraries-preserving-header-directory-structure.html). we have `primitives.h` in different folders and they would be flattened into `React_Fabric.framework/Headers`. to be honest, i don't know how to deal with the problem in the meantime, maybe subspecs are not enough, we should separate them from subspecs to dedicated podspecs so that we can have these targets as different frameworks.
in this alternative fix, i try to add `React-Codegen/React_Codegen.framework/Headers` into header search paths and make original `#import <FBReactNativeSpec/FBReactNativeSpec.h>` reachable.
[this change](https://github.com/facebook/react-native/commit/7a0398c331f22abc619a64b444ec7153357b0a30) in the pr is just a workaround to solve breaking in latest main branch and this is not important to the `use_frameworks!` fix at all. this breaking was coming from https://github.com/facebook/react-native/commit/180495159517dc0bfa103621e5ff62fc04cb3c8b.
[iOS] [Fixed] - Fix iOS build error when Podfile `use_frameworks!` is on and Fabric is off
Pull Request resolved: https://github.com/facebook/react-native/pull/33409
Test Plan:
verify with rn-tester
1. change `fabric_enabled` to false in `packages/rn-tester/Podfile`
2. `USE_FRAMEWORKS=1 pod install`
3. build rn-tester in xcode
Reviewed By: dmitryrykun
Differential Revision: D34817041
Pulled By: cortinico
fbshipit-source-id: 4d1a610e99a807793eb3f64461e0d735c0a9ca9c
Summary:
Time to release a new version of the Gradle plugin and bump it to 0.0.5
This version includes a deprecation of `reactRoot` and a warning message
to migrate to `root`/`reactNativeDir`.
Changelog:
[Android] [Changed] - Release react-native-gradle-plugin 0.0.5
Reviewed By: ShikaSD
Differential Revision: D34339272
fbshipit-source-id: c03495bda7c4185d674761e58a94fde8612f2941
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/33142
The `reactRoot` property was confusing as we were using it for both the root of the project
and the react-native NPM Package root. I'm deprecating it and splitting it in two.
I've added several warning in the codebase to tell the people how to migrate away from it.
Moreover this is specifying default values that are more user-friendly. Users won't have to
configure anything unless they are in a monorepo.
Changelog:
[Android] [Changed] - Gradle: Deprecate `reactRoot` in favor of `root` and `reactNativeDir`
Reviewed By: ShikaSD
Differential Revision: D34277050
fbshipit-source-id: fc7f45017452b086726516a9586cacd9a661c287
Summary:
This is necessary otherwise when building from source on JVM < 11, the `compileJava`
task of the Gradle Plugin will fail with `invalid source: 11`.
Essentially the Gradle build will not even start because of this. Instead we delegate
to a better formatted warning from either AGP or from our plugin.
Changelog:
[Internal] [Changed] - Set Java source/target compatibility for react-native-gradle-plugin to 8
Reviewed By: ShikaSD
Differential Revision: D34111799
fbshipit-source-id: 57ab11fe6c4532576776b586f75e8fcb5c71adcd
Summary:
you can see discussion here: https://github.com/reactwg/react-native-releases/discussions/13#discussioncomment-2069527
we were getting this error message when we build Gradle with other than 11 JVM
```
> Task :react-native-gradle-plugin:compileJava FAILED
2 actionable tasks: 2 executed
FAILURE: Build failed with an exception.
* What went wrong:
Execution failed for task ':react-native-gradle-plugin:compileJava'.
> invalid source release: 11
```
this solution is suggested by mikehardy
after this PR, now the error is like this
```
**************************************************************************************************************
ERROR: requires JDK11 or higher.
Incompatible major version detected: '8'
**************************************************************************************************************
```
## 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
-->
[Android] [Fixed] - jvm 11 error message
Pull Request resolved: https://github.com/facebook/react-native/pull/33048
Test Plan: install other than 11 java version and just run `./scripts/test-manual-e2e.sh` this command at the root of RN repo than this error will appair `invalid source release: 11`
Reviewed By: ShikaSD
Differential Revision: D34110990
Pulled By: cortinico
fbshipit-source-id: c142a363c7cec0db65d5ab9da858fd25866c7c49
Summary:
Creates a new package called `fb-tools-support/yarn` and moves the `getWorkspacesFromYarn` function (currently duplicated almost verbatim in two places) into that shared location.
Also, gets `yarn postinstall` to work again and runs it in `xplat/js` - this materialises some new BUCK files that weren't added when their respective Yarn workspaces were created.
Reviewed By: rh389
Differential Revision: D33826945
fbshipit-source-id: 02e2db8b210303ed4f6d24a777a2e0094022bd5d
Summary:
Dynamic nested components can cause tricky performance issues in React, as the reconciler will not be able to reuse the previously mounted component tree.
Changelog: [General] [Added] Added linter warning config for unstable nested components
Reviewed By: motiz88
Differential Revision: D33767283
fbshipit-source-id: 869ece99dc63cc3a150bae882d26df8541e8db59
Summary:
`Easing` only has static properties and is never constructed or subclassed, so there doesn't seem to be any reason for it to be a class instead of an object.
as a class, Flow errors about `method-unbinding` on every single use of it.
Changelog: [Internal]
Reviewed By: motiz88
Differential Revision: D33774944
fbshipit-source-id: c0bd2e3d7a78e538f95b88b2b1b12d301c8f590c
Summary:
Bump Kotlin version to 1.6.10 with changes:
https://kotlinlang.org/docs/whatsnew16.html
Primarily:
- stabilization to several language features
- various type inference improvements
- support for annotations on class type parameters
## Changelog
[Android] [Changed] - Bump Kotlin version to 1.6.10
Pull Request resolved: https://github.com/facebook/react-native/pull/32936
Reviewed By: ShikaSD
Differential Revision: D33708397
Pulled By: cortinico
fbshipit-source-id: a09b4504c194676d18a749c5e297b7598e5f32b4
Summary:
Bump react-native-codegen version to include new fixes and improvements.
Changelog: [internal] Updated react-native-codegen version
Reviewed By: cortinico
Differential Revision: D33684175
fbshipit-source-id: bfc6cb627659c7cdfca2676894bece5f02aff767
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/32923
As our Flipper version is quite old, let's bump it to one of the latest stable: 0.125.0
This required to update also the following:
- Flipper-Folly to 2.6.10 - This was needed as I aligned the versions to https://github.com/facebook/flipper/blob/v0.125.0/react-native/ReactNativeFlipperExample/ios/Podfile
- OpenSSL-Universal to 1.1.1100 - This was required with the `pod update` command
I've picked 0.125.0 as 0.127.x and following are crashing on Android
and will potentially require a bump of the NDK to r23:
See: https://github.com/facebook/flipper/issues/3245
Changelog:
[General] [Changed] - Bump Flipper to 0.125.0
allow-large-files
Reviewed By: mdvacca
Differential Revision: D33583090
fbshipit-source-id: 2a2020c3213273087ec4a152076f846e35e275c5
Summary:
Changelog: [Internal] Update the documentation to disable fabric in RN Tester.
RNTester build would fail if you previously built with fabric_enabled. This documentation adds the instruction to clean up before runing pod install.
In the future, we'd want to detect and do the clean up so that it doesn't fail in an obscure way.
Reviewed By: cortinico, dmitryrykun
Differential Revision: D33173173
fbshipit-source-id: a396eb71edc7bf174d0eb392799f45ae74274b76
Summary:
I realized while checking for a few other things that Detox's presence in the repo is actually not really motivated - since Jul 2020 the few tests that were using it were disabled https://github.com/facebook/react-native/commit/120ff7ccdebebdf814e478259ba1e4a8ef6f513e never to be reactivated since.
I noticed this while attempting to updating the Detox version to latest... which made me notice that the repo is still on a 16.x version while latest is 19.x (there are like 10 pages of releases between them: https://github.com/wix/Detox/releases) and I came to the conclusion that it's probably easier to just remove the old dusty code and eventually reintroduce it in the future if we ever consider it necessary.
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://github.com/facebook/react-native/wiki/Changelog
-->
[General] [Removed] - Removing Detox from CI.
Pull Request resolved: https://github.com/facebook/react-native/pull/32907
Test Plan: CI - nothing breaks.
Reviewed By: lunaleaps
Differential Revision: D33623199
Pulled By: cortinico
fbshipit-source-id: 7d8d133629b62b66959b309f2ca21852d396c9fc
Summary:
Fix an issue in the AccessibilityExample on RNTester where the `Screen Reader` item would listen for the `reduceMotionChanged` event instead of the `screenReaderChanged` event
## Changelog
[General] [Fixed] - Fix screen reader event name on RNTester AccessibilityExample
Pull Request resolved: https://github.com/facebook/react-native/pull/32926
Test Plan:
1. Build iOS app
2. Navigate to the Accessibility page
3. Switch over to settings and change VoiceOver at `Settings>Accessibility>VoiceOver>VoiceOver`
4. Switch back to the app and see the results
https://user-images.githubusercontent.com/11707729/150266745-6a9eb547-00a7-4b94-bf19-b8d6e6f76122.mp4
Reviewed By: kacieb
Differential Revision: D33681780
Pulled By: cortinico
fbshipit-source-id: fbd4f3d9ef63997f2b4a40afc8a5adfe6172e525
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/32932
As the title says, we dont' want to remove `libjscexecutor.so` when
baking release builds and having JSC enable as this leads to instacrashes.
Fixes#32928Fixes#32927
Changelog:
[Android] [Fixed] - Do not remove libjscexecutor.so from release builds
Reviewed By: ShikaSD
Differential Revision: D33681932
fbshipit-source-id: 5b59fd1fb76c80c191198d65c916bbbd9232c75b
Summary:
Changelog: [General][Fix] Fix SnapshotExample in rn-tester
Before this diff, the <Image> has no height. You can tell because the backgroundColor of <Image> is black but it doesn't show up on this surface.
Reviewed By: RSNara
Differential Revision: D33649085
fbshipit-source-id: 1b0fa0a82bce29923afee000d0828cbd90845abf
Summary:
Flow currently allows duplicate members on classes. At runtime the "last" member wins out and all previous values for the member are discarded.
This diff manually removes duplicate members, and fixes resulting flow errors by converting methods to arrow function properties.
Reviewed By: pieterv
Differential Revision: D33664966
fbshipit-source-id: 0f712ac96af4df593c0918fcbadd70624ddde4a6
Summary:
Changelog: [JS] Migrate ScreenshotManager from NativeModule to TurboModule. Fix SnapshotExample in rn-tester.
`const ScreenshotManager = NativeModules.ScreenshotManager;` makes all of RNTesterAppRoute render blank in Bridgeless, because we throw a jsi::JSError when JS calls `NativeModule.get` while in Bridgeless.
Reviewed By: RSNara
Differential Revision: D33640935
fbshipit-source-id: 124a3b43e1440a7ca0071c95c4388350d2e4affa
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/32840Closes#31516
I've cherry-picked the original PR that had merge conficts + updated all
the headers as the one for the TurboModule generators were not handled.
Original Commit Message from acoates
The codegen generates a Facebook copyright notice at the top of the generated files.
While this might make sense on the core files, this codegen will be run on external components too.
The notice also refers to a LICENSE file in the root of this project, which might not be there if this is run on another project.
I did a quick look at some of the codegen that we ship within windows dev tools, and it looks like we normally just have comments
saying the file was codegen'd and so the file shouldn't be manually edited.
Open to suggestions on what the comment header should say.
Changelog:
[General] [Changed] - Do not include Facebook license on users codegen'd code
Reviewed By: ShikaSD
Differential Revision: D33455176
fbshipit-source-id: b247e72efb242e79d99b388c80e4126633e5234d
Summary:
`const {CrashyCrash} = NativeModules` makes all of RNTesterAppRoute render blank in Bridgeless.
Remove this test example because the CrashyCrash has not existed since 2019, and no similar module exists in open source. [[github]](https://github.com/facebook/react-native/commit/8ec7e0966cf83ed29a39aab47c686bc60a124983)
Changelog: [Internal]
Reviewed By: philIip
Differential Revision: D33644122
fbshipit-source-id: ed10e8bf8ea9af9d5904afc2a7d9c2b3b3606978
Summary:
Gradle Plugin Portal proxies jcenter which is quite unstable these days. This change updates plugin repositories to look into maven central and google first and use gradle plugin repo only as a fallback.
Changelog: [Internal] - Prioritize maven central for Gradle plugins
Reviewed By: cortinico
Differential Revision: D33550827
fbshipit-source-id: b436b05b0fd07865b56dd3e442d8399678dfff85
Summary:
I'm bumping the Gradle Plugin to the latest stable. That's needed as the newest
plugin now specifies a Maven `group` and can leverage implicit dependency substitution.
Changelog:
[Internal] [Changed] - Bump gradle-plugin to 0.0.4
Reviewed By: ShikaSD
Differential Revision: D33530286
fbshipit-source-id: 904f0a6585b468322f611ed82c57cee7025305d7
Summary:
## Context
Inside native ViewConfigs, events are declared using these bubbling/direct EventType maps:
```
{
uiViewClassName: '...',
bubblingEventTypes: {
topFoo: {
registrationName: "onFoo"
}
},
directEventTypes: {},
validAttributes: {
},
}
```
**Pattern:** Note that the top name (i.e: topFoo) is just the registration name (i.e: onFoo) but with "on" replaced with "top".
On Android, registration names and top names don't have to follow this pattern. The top name can be **anything.** See ReactionsDockView:
https://www.internalfb.com/code/fbsource/[c430d46ed69a03a9d9f40cefa335a6d8bb92f8ec]/fbandroid/java/com/facebook/feedback/reactions/ui/overlay/react/ReactionsDockViewManager.java?lines=26-28%2C32-34%2C38
Here, ReactionDismissedEvent.EVENT_NAME is "topDismiss"
https://www.internalfb.com/code/fbsource/[c9f92314a5c46e561a831100dab82164808b05d0]/fbandroid/java/com/facebook/feedback/reactions/ui/overlay/react/ReactionDismissedEvent.java?lines=10-11%2C26
And so to provide you the flexibility to specify a custom topName, the codegen supports a customTopName in the direct/bubbling event types:
```
onDismissWithFeedbackReaction: DirectEventHandler<Event, 'topDismiss'>,
```
This generates the two bubbling event type entries in ReactionsDockView:
```
{
uiViewClassName: '...',
bubblingEventTypes: {
// custom top name
topDismiss: {
registrationName: "onDismissWithFeedbackReaction"
},
// what the top name should actually be
topDismissWithFeedbackReaction: {
registrationName: "onDismissWithFeedbackReaction"
}
},
directEventTypes: {},
validAttributes: {
},
}
```
**The Problem:** The entry created for "topDismissWithFeedbackReaction" is not necessary. This additional entry creates a discrepancy between ReactionsDockView's static ViewConfig and native ViewConfig. Therefore, this diff removes the second unnecessary entry.
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D33418730
fbshipit-source-id: 3988ff6906ad1b2e1ef988a19c64d1e042381ab1
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/32848
If we leverage the side-by-side configuration of the NDK
(see https://developer.android.com/studio/projects/configure-agp-ndk#agp_version_41)
we will not have to specify the NDK Path or Version at all.
We will automatically pick the best NDK version selected by AGP.
Changelog:
[Android] [Changed] - Use side-by-side NDK for Android
Reviewed By: ShikaSD
Differential Revision: D33475818
fbshipit-source-id: 16aa4acfc44b94e2f92df89d71e104bf46d7f162
Summary:
Previously we asked users to specify a dependency substitution
rule to properly use the React Native Gradle Plugin.
Here I'm updating the Gradle Plugins setup to allow to use implicit
dependency substitution. This requires to specify a Maven Group and Artifact
Name (through the project name).
This is backward compatible as users will still be allowed to specify a
dependency substitution rule if they wish.
Changelog:
[Android] [Changed] - Leverage Gradle implicit dependency substitution for Gradle Plugin
Reviewed By: ShikaSD
Differential Revision: D33404948
fbshipit-source-id: 3323f8e0738fd579ce8ae344cbdc0e4356e7dbd8
Summary:
With SVC enabled for codegenNativeComponent, use `UIManager.hasViewManagerConfig(viewManagerName)` instead of `UIManager.getViewManagerConfig(viewManagerName)` to check for whether the native component is in the app BUCK binary.
This is safe because `global.__fbStaticViewConfig` is gated with MC, and the purpose of SVCs is to stop using `getViewManagerConfig` to get view configs from the Paper view managers. Currently no QEs have SVCs enabled.
Changelog:
[Fabric][JS] For codegenNativeComponent, with SVC enabled, use UIManager hasViewManagerConfig instead of getViewManagerConfig
Reviewed By: RSNara
Differential Revision: D33511365
fbshipit-source-id: 58c7020903137e2b5c80ef34a956be04de51628b
Summary:
For every direct and bubbling event, RCTComponentData (iOS-only) creates a {eventName}: true entry in the component's ViewConfig validAttributes. This entry is unnecessary, and creates a discrepancy between ViewConfigs on iOS vs Android.
This diff removes this entry for all events to:
1. Reduce bloat in native ViewConfigs
2. Create consistency betweeen Android and iOS.
Changelog: [Internal]
Reviewed By: yungsters
Differential Revision: D33303950
fbshipit-source-id: 870c8a2a6d41156ac89bd8554eb09f292bb6108e
Summary:
Let's keep our Gradle infra deps up to date.
I'm bumping Gradle to 7.3.3 which fixes several Log4j CVEs,
AGP to 7.0.4 and the Download Task plugin to 4.1.2
Changelog:
[Android] [Changed] - Bump Gradle to 7.3.3 and AGP to 7.0.4
Reviewed By: mdvacca
Differential Revision: D33430789
fbshipit-source-id: b8f260beb4a9cc962ea3743610bfb4ead004d6cb
Summary:
Renaming the `better` utilities to `butter`:
- to prevent claims that this library is superior to others - it really depends on use cases
- to indicate ease of use throughout the codebase, easily spread like butter
Changelog: [C++][Changed] Renaming C++ better util to butter, used by Fabric internals
Reviewed By: JoshuaGross
Differential Revision: D33242764
fbshipit-source-id: 26dc95d9597c61ce8e66708e44ed545e0fc5cff5
Summary:
Tests for Native Modules. Fixtures, Failures and the e2e tests were copied from the flow parser, modified for TypeScript and then the snapshots were diff'ed to ensure the parsers generated the same schema given the same (in spirit, different in syntax) input.
Changelog:
[General][Add] - Tests for TypeScript support for Native Module Codegen spec parsing
Reviewed By: RSNara
Differential Revision: D33081127
fbshipit-source-id: 3d7270dddd568090ec93d475a08a6a6011dad63c
Summary:
Tests for Native Components. Fixtures, Failures and the e2e tests were copied from the flow parser, modified for TypeScript and then the snapshots were diff'ed to ensure the parsers generated the same schema given the same (in spirit, different in syntax) input.
Changelog:
[General][Add] - Tests for TypeScript support for Native Component Codegen spec parsing
Reviewed By: RSNara
Differential Revision: D33080789
fbshipit-source-id: ae71d384f6d93da6b89eeb179c4ba7ebcd6ae03d
Summary:
These files are directly copied from the flow parser to aid in reviewing the next two Diffs: D33080789 and D33081127.
The only things that were changed during the copy are the import/require paths to ensure this diff could ship independently. (For this diff, these tests will still test the flow parser instead of importing the typescript parser).
Changelog:
[Internal][Add] - Copy Flow parser tests to aid in Diff review
Reviewed By: RSNara
Differential Revision: D33136296
fbshipit-source-id: 007e18618c9eba13728d19e4e342fbe9642adacc