Summary:
Task from https://github.com/facebook/react-native/issues/34872
> [Codegen 82] Move isModuleInterface function (Flow, TypeScript) to the Flow and TypeScript parsers.
## Changelog
[INTERNAL] [CHANGED] - Moved isModuleInterface function to to the Flow and TypeScript parsers.
Pull Request resolved: https://github.com/facebook/react-native/pull/36268
Test Plan: ` yarn test react-native-codegen`
Reviewed By: christophpurrer
Differential Revision: D43535948
Pulled By: rshest
fbshipit-source-id: 7a2db05008783499168b0ce3fa58fedbac2b4e79
Summary:
Add performance API example to RN tester, start with the `performance.memory` API.
- Update `RNTesterList` file for both android and ios
Changelog:
[General][Internal] - Add `performance.memory` API example to RNTester
Reviewed By: rshest
Differential Revision: D43326565
fbshipit-source-id: adeb18ce9f1f90d9e9ecf66b533307028bc02df8
Summary:
changelog: [internal]
Move initialisation to `init` function. This allows subclasses of `RCTAppDelegate` to use new architecture when overriding `didFinishLaunchingWithOptions`
Reviewed By: cipolleschi
Differential Revision: D43535602
fbshipit-source-id: 32adb5416e67a63ad168f0ed2480287bf178a6a6
Summary:
Adding automatic RN version checking github workflow, which will verify the version of RN listed on all new issues filed in the repository.
Additionally, this change refactors the existing labeler workflow to make it re-usable by the version check workflow. The change also creates a logical place to add future automatic detection checks, like auto-verification of repro, template, etc.
This is technically not new functionality, as the react-native-bot does this _sometimes_, but this should be a lot more reliable.
The logic for valid release checking follows what is listed in the documentation - valid versions are current and N-2 minors, with the highest available patches.
## Changelog
[INTERNAL] [FIXED] - Made the automated RN version checking workflow more reliable
Pull Request resolved: https://github.com/facebook/react-native/pull/36075
Test Plan:
I have verified a variety of different versions on issues here: https://github.com/SlyCaptainFlint/react-native/issues
I have also re-verified all the tags that were previously handled by the labeler workflow, since I have refactored it. Please take a look at both the open and closed issues in the linked repo for examples.
Reviewed By: cortinico
Differential Revision: D43089150
Pulled By: SlyCaptainFlint
fbshipit-source-id: 7da67f5cb2a4875f22e1f9e46d7ca07d43f3e135
Summary:
Changelog:
[Android][Internal] - Fix EventAnimationDriverMatchSpec to match against the view that generated the event for non-bubbling pointer events. This should have no effect if you are not using PointerEvents
Reviewed By: mdvacca
Differential Revision: D43413771
fbshipit-source-id: 31ac751b3d3d55eb44d3a9ab54e5fb387dcaa9b3
Summary:
After reviewing the doc [`Image`](https://reactnative.dev/docs/image), the typescript compiler doesn't know the following properties:
- src
- srcSet
- referrerPolicy
- tintColor
- objectFit
But after reviewing the source code and this [`commit`](b2452ab216), the `objectFit` property isn't one related to the Image component but to the `style` props, making the official doc outdated. So, an [`issue in the react-native-website repo`](https://github.com/facebook/react-native-website/issues/3579) have been created and I decided to not include the objectFit prop in this PR.
So, this PR includes those properties: sec, secSet, referrerPolicy and tintColor
## Changelog
[GENERAL][FIXED] Add src, srcSet, referrerPolicy, tintColor to Image.d.ts declaration file
Pull Request resolved: https://github.com/facebook/react-native/pull/36214
Reviewed By: NickGerleman
Differential Revision: D43437894
Pulled By: rshest
fbshipit-source-id: 497426490134aba0a474c49bf8bab9131f2e5845
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36177
react_native_assert calls C `assert()`, where XCode does not have a built-in breakpoint navigator to hook to assertion failures (though you can add a symbolic breakpoint to "abort()" to get the effect). This changes the Apple implemented of `react_native_assert()` to use `NSCAssert` under the hood. This is safe to use in C functions, but will be trapped by the default XCode exceptions breakpoint navigator.
Changelog:
[iOS][Fixed] - Use NSCAssert() in react_native_assert instead of C assert()
Reviewed By: cipolleschi
Differential Revision: D43275024
fbshipit-source-id: 43c4e4f1ae6b99f32634d4b1880bce712c3ae8f6
Summary:
Opts `fbsource//xplat/js/react-native-github/packages/rn-tester:RNTesterIntegrationTests` out of Buck2 runs as the target fails in the analysis stage due to some flavor issues.
I did experiment with just resolving the flavor issues but several more nontrivial issues show up in the build graph the deeper you go and I think this target is going to require a bit more of a deep dive, so just disabling it to unblock buck2 CI rollout for now.
Reviewed By: bujar
Differential Revision: D43505883
fbshipit-source-id: 672dc6aea345a8c0396f6a0e3d549016fe1f7c45
Summary:
This diff is a retry of shipping D43180893 (89ef5bd6f9), which got backed out in D43350025 (1f151e0d2f) due to issues in iOS RN apps.
I've exclude iOS apps in this diff. I am planning to have the iOS implementation for the TraceUpdateOverlay native component to fill the gap with lower priority.
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D43409501
fbshipit-source-id: fe8bb5654862f0b5e9054a97ae1f4cde573bb3e0
Summary:
When developing the changes to support `use_frameworks!`, I may have forgotten to update the script that generate the `FabricComponentProvider` for the open source (and I may have changed directly that file manually to make everything work).
This change restore the generator, using the right `#import statement`
allow-large-files
## Changelog
[internal] - Update plugin generator
Reviewed By: arushikesarwani94
Differential Revision: D43504184
fbshipit-source-id: a89455b62115f6dc2054f804241fd3834056f1b3
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36253
Another build warning that got converted into a failure in Gradle 8.x
Specifically here as we're running 4 native builds in parallel for RN Tester, but they all originate
from 2 CMake intermediates files (one set for Debug and one for Release), Gradle raises a warning.
Here I'm fixing this warning by specifying an explicit ordering between those tasks.
Changelog:
[Internal] [Changed] - Gradle 8.x prep - specify task dependency between mergeNativeLibs and external native builds
Reviewed By: cipolleschi
Differential Revision: D43501128
fbshipit-source-id: bb40ae902157ce97683f42124ec65f2bc0d73405
Summary:
I'm widening the exclude for GenerateCodegenSchemaTask input files.
This is needed before we can migrate to Gradle 8.x as one of the build warning we have is
now converted to a build failure.
The reason why this is needed is because GenerateCodegenSchemaTask ends up picking up a file that
gets generated by `react-native bundle`. While the file is ignored by the Codegen, Gradle
detects a clash between the two tasks.
This solves the issue completely.
Changelog:
[Internal] [Changed] - RNGP - GenerateCodegenSchemaTask should exclude all of `**/build/[generated|intermediate]**`
Reviewed By: cipolleschi
Differential Revision: D43501129
fbshipit-source-id: 49311b833d6b59d4e67e87c535a424a1db1321e6
Summary:
I've just tested the nightly and the build from source is broken as the `repositories{}` block is missing.
Normally RNGP will take care of setting repositories for everyone, but this is triggered by the app-module.
When building from source, the app module of the user is isolated from the included build of React Native,
therefore the repositories{} definitions are not passed over.
Without this, the build fails with:
```
Cannot resolve external dependency ... because no repositories are defined
```
Changelog:
[Internal] [Changed] - Re-add repositories{} block to allow for build-from-source
Reviewed By: cipolleschi
Differential Revision: D43501011
fbshipit-source-id: b41c56c62839163ad210e7e303940dec0a9001da
Summary:
I noticed this stale directory and snapshot tests for RN-Tester. We might as well just remove them.
## Changelog
[INTERNAL] [REMOVED] - Remove more tvos remnants
Pull Request resolved: https://github.com/facebook/react-native/pull/36240
Test Plan: CI should pass.
Reviewed By: cipolleschi
Differential Revision: D43495264
Pulled By: cortinico
fbshipit-source-id: 7286cf6805e12249db5d71bcaa9a91bc947102ca
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36227
This is needed for the next Gradle major (8.x) and re-aligns us with the
Kotlin version in fbsource
Changelog:
[Android] [Changed] - Kotlin to 1.7.22 for Gradle
allow-large-files
Reviewed By: rybalkinsd
Differential Revision: D43445999
fbshipit-source-id: 85be1bbb4b5ac1664b5090688b688a4e50c3d80a
Summary: Changelog: [Android][Fixed] Resolved bug with Text components in new arch losing text alignment state.
Reviewed By: mdvacca
Differential Revision: D34108943
fbshipit-source-id: 3992e9406345be919b5e3595fc1f9e61cf67a699
Summary:
Simple optimization to exit before iterating through the hit path if the event name doesn't match.
Changelog:
[Android][Internal] - Optimization for natively-driven Animated PointerEvents to early exit during matching in EventAnimationDriverMatchSpec. This should have no effect if you are not using PointerEvents
Reviewed By: lunaleaps
Differential Revision: D43400457
fbshipit-source-id: fe8d811d371c78622cd4f3f9cd469cff9ccce585
Summary:
[Changelog][Internal]
This adds a method, `emitDeviceEvent` to the C++ API of TurboModules, which allows to make calls to JS's `RCTDeviceEventEmitter.emit` from a C++ TurboModules.
This is a very common pattern, specifically for the VR apps, but not only for them - e.g. Desktop fork also has a [custom implementation for this](https://www.internalfb.com/code/fbsource/third-party/microsoft-fork-of-react-native/react-native-utils/RCTEventEmitter.cpp).
Note that my original intent was to actually backport the latter, however there are some complications with wiring things in a robust way, without exposing too much stuff and relying on singletons or folly::dynamic.
So I ended up adding it to the TurboModule API itself and use the scheduler/JSI facilities instead.
This approach is arguably well self-contained, uses high level APIs, and shouldn't be abusable much.
Since I was trying to avoid usage of folly::dynamic in this case, I used a kind of "value factory" pattern instead in order to send the arguments to the JS thread in a thread safe way (see [the discussion here](https://fb.workplace.com/groups/rn.fabric/permalink/1398711453593610/)).
Reviewed By: christophpurrer
Differential Revision: D43466326
fbshipit-source-id: a3cb8359d08a46421559edd0f854772863cb5c39
Summary:
This adds a series of examples for TextInput styles to screenshot test, specifically the ones which are projected to Android as spans. This will be used in refactoring to verify we do not change visual output.
Changelog:
[Internal][Added] - Add "Text Styles" TextInput Example
Reviewed By: cortinico
Differential Revision: D43158004
fbshipit-source-id: adaecf0e37941e66e280db282e2631a95b08b27a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36232
Seems like RN Tester is crashing for JSC debug/release.
This happens because RN Tester ends up fetching JSC from Maven Central which contains older versions
of the artifacts (r17) which are not compatible with our setup AND are missing `libjsc.so`.
This is happening as our file layout is a bit different than a regular NPM project so
the repository declaration for JSC, being `../jsc-android/dist` from React Native root ends
in the wrong folder.
In this specifically I:
- Add an excludeModule for "org.webkit:android-jsc" on Maven Central inside RNGP
- Remove the allproject{repositories{}} block which was overriding RNGP configuration
- Add a specific repository declaration inside RN Tester to point to where JSC effectively lives
Changelog:
[Internal] [Changed] - RNGP - Fix RNTester crashing for JSC and safeguard against fetching JSC from Maven Central
Reviewed By: sshic
Differential Revision: D43462015
fbshipit-source-id: db830d7567bbf7dd91412df417418aa61a0ca8fe
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36209
ThisChange automatically enable the RuntimeScheduler when the new architecture is enabled, both on RNester and in the Template app.
Note that no migration steps are required.
## Changelog
[iOS][Changed] - Automatically install the RuntimeScheduler
Reviewed By: sammy-SC
Differential Revision: D43392059
fbshipit-source-id: 609ded9bdc3db13a0d54ff44d0d4687dfc8617a5
Summary:
> [Codegen 85] The parses/flow/components/schema.js and parses/typescript/components/schema.js are the same. Move the schema.js from the one of the two folders to the parsers common root. Delete the other. Update the references to use the shared file.
Part of the Codegen ☂️ Issue https://github.com/facebook/react-native/issues/34872
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
[ANDROID|GENERAL|IOS|INTERNAL] [BREAKING|ADDED|CHANGED|DEPRECATED|REMOVED|FIXED|SECURITY] - Message
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[Internal] [Changed] - Consolidated the schema.js files for parses/flow/components and parses/typescript/components to a common root.
Pull Request resolved: https://github.com/facebook/react-native/pull/36219
Test Plan: Run ```yarn jest react-native-codegen```
Reviewed By: christophpurrer
Differential Revision: D43444666
Pulled By: cipolleschi
fbshipit-source-id: 24d791fd3a8110730d3f6054497ea3a31549a5a5
Summary:
Callling `getReactApplicationContextIfActiveOrWarn` from `invalidate` will always warn because the context is deactivated, which is preventing us from cleaning up these listeners.
Changelog: [Internal]
Reviewed By: jehartzog
Differential Revision: D43352929
fbshipit-source-id: f29564a290a6c93b2304865d445829f5e486d84f
Summary:
Having custom commit message script is not an option for `main` branch, because we have internal tooling, which strips `[x]` tags from commit messages before merging them into `main` branch.
Instead of constant commit message, we are now using a tag which will be concatenated with the commit message, which was entered via interactive commit dialog, see demo below.
## Changelog
[Internal] - updated validation in bumping packages script
Pull Request resolved: https://github.com/facebook/react-native/pull/36220
Test Plan: https://user-images.githubusercontent.com/28902667/220163767-015bf37b-6914-4df2-84d9-aa25fb2887d3.mov
Reviewed By: cortinico
Differential Revision: D43443597
Pulled By: hoxyq
fbshipit-source-id: 08e5e08524a1d934fbb35529e025358d7bf3b203
Summary:
Relative path in conditional IF in settings.gradle.kts doesn't work when it try to build (`yarn install-android-jsc`) a package that isn't in root dir and needs of react-native-gradle-plugin or when it try to run rn-tester.
When trying to compile rn-tester (`yarn install-android-jsc` command) the error below:
```Shell
arthur@assuncao � ~/projects/react-native-test/react-native/packages/rn-tester � � main � yarn install-android-jsc
yarn run v1.22.19
$ ../../gradlew :packages:rn-tester:android:app:installJscDebug
Starting a Gradle Daemon (subsequent builds will be faster)
FAILURE: Build failed with an exception.
* What went wrong:
Project directory '/home/arthur/projects/react-native-test/react-native/packages/rn-tester' is not part of the build defined by settings file '/home/arthur/projects/react-native-test/react-native/settings.gradle.kts'. If this is an unrelated build, it must have its own settings file.
* Try:
> Run with --stacktrace option to get the stack trace.
> Run with --info or --debug option to get more log output.
* Get more help at https://help.gradle.org
BUILD FAILED in 8s
error Command failed with exit code 1.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.
```
## Changelog
[INTERNAL] [FIXED] - Fix conditional to include rn-tester and react-native-gradle-plugin in settings.gradle.kts.
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
Pull Request resolved: https://github.com/facebook/react-native/pull/36188
Test Plan:
Execute rn-tester like [(RN-Tester Readme)](https://github.com/facebook/react-native/blob/main/packages/rn-tester/README.md).
After my changes, the output of `yarn install-android-jsc` is:
```Shell
[... many of the other tasks completed above]
> Task :packages:rn-tester:android:app:compileJscDebugJavaWithJavac
Note: Some input files use or override a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
> Task :packages:rn-tester:android:app:stripJscDebugDebugSymbols
Unable to strip the following libraries, packaging them as they are: libicu_common.so.
> Task :packages:rn-tester:android:app:installJscDebug
Installing APK 'app-jsc-arm64-v8a-debug.apk' on 'ASUS_Z01KD - 8.0.0' for :packages:rn-tester:android:app:jsc-debug
Installed on 1 device.
BUILD SUCCESSFUL in 31m 53s
121 actionable tasks: 121 executed
Done in 1913.92s.
```
This PR Resolves https://github.com/facebook/react-native/issues/36187
Reviewed By: rshest
Differential Revision: D43393440
Pulled By: cortinico
fbshipit-source-id: 824644aa77147b3747007908db11fe9c120ad92f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36148
This change enables 4 noew tests to make sure that `use_frameworks!` with the New Architecture don't break
Note: We may have to publish the codegen to make this work on CircleCI properly
## Changelog:
[iOS][Added] - Added tests for use_frameworks! with the new architecture
Reviewed By: cortinico, dmytrorykun
Differential Revision: D43271625
fbshipit-source-id: fe1fa4be660f933e0113f44a0467eaa1fa3669ca
Summary:
By leveraging the `PUBLIC_HEADERS_FOLDER_PATH` build settings of Xcode, we can instruct cocoapods to generate the frameworks Headers in a specific folder, for example the `React` folder.
This allows us to maintain the `#include`/`#import` structure, even if the framework has a different name.
However, we need to update the search paths to take into account this extra folder.
## Changelog:
[iOS][Changed] - Generate RCTFabric framework's headers in the React folder
Reviewed By: sammy-SC, dmytrorykun
Differential Revision: D43425677
fbshipit-source-id: 94a4f3a3c7de86341b3ce3457704e6b8fb9a588e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36210
One of the circular dependencies we have in OSS was between React-Codegen and React-Fabric.
React-Codegen generates component which has to depends on React-Fabric because they need to use the files contained in the `react/renderer/view` folder.
React-Fabric contains some components that depends on RNCore, which was generated inside the React-Codegen folder.
This change generates the RNCore components inside the `ReactCommon/react/renderer/components/rncore` folder, breaking the dependency as `rncore` folder is now contained by React-Fabric itself.
**Fun Fact:** That's how it always should have been. There was already a line in the `.gitignore` to exclude the content of `ReactCommon/react/renderer/components/rncore` folder. I guess that with some of the refactoring/previous projects on Codegen, this requirements has slipped.
## Changelog:
[iOS][Breaking] - generates RNCore components inside the ReactCommon folder and create a new pod for platform-specific ImageManager classes
Reviewed By: sammy-SC, dmytrorykun
Differential Revision: D43304641
fbshipit-source-id: ebb5033ce73dbcd03f880c3e204511fdce04b816
Summary:
This diff update the Cocoapods scripts to install the proper dependencies and search paths when `use_frameworks!` is declared together with the New Architecture.
Practically, it adds the right search paths to the codegen and the project files and makes sure that third party dependencies that leverage the `install_modules_dependencies` are populated with the right search paths for Frameworks.
It also adds unit tests for the changes and the new methods introduced.
## Changelog:
[iOS][Changed] - Properly install dependencies with `use_frameworks!`
Reviewed By: sammy-SC, dmytrorykun
Differential Revision: D43089869
fbshipit-source-id: 1981b6853f774fdb3dbe8d17ea37fd5154c54b25
Summary:
Update podspecs with the right search paths to include the required framework by every module.
## Changelog:
[iOS][Changed] - Update search paths to support `use_frameworks!` with Fabric
Reviewed By: sammy-SC, dmytrorykun
Differential Revision: D43089372
fbshipit-source-id: 4bbfc4b98bd289d66ce4015429d581856d9c05b3
Summary:
This change solve a Circular Dependency where
- `React-Core` depends on `ReactCommon` because `RCTAppSetupUtils.h` (in Core) imports the `RCTTurboModuleManager` (from ReactCommon)
- `RCTTurboModuleManager` in `ReactCommon` depends on `React-Core` because it imports several classes from it (e.g. the `RCTBridge` class)
## Changelog:
[iOS][Breaking] - Moved the RCTAppSetupUtils to the AppDelegate library to break a dependency cycle
Reviewed By: sammy-SC, dmytrorykun
Differential Revision: D43089183
fbshipit-source-id: d7fc36a50811962caf7cff77bb45d42b8cdd4575
Summary:
[Changelog][Internal]
A follow-up, based on javache comments on D43398416 (9aac13d4dc) (post-land) - just some minor potential improvements for locking efficiency.
Reviewed By: javache
Differential Revision: D43438414
fbshipit-source-id: 0cf807a045a1f132d5481d3f6115a97869e93d65
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36217
## Bump minimum Node JS version to 16 via `react-native/package.json#engines`
In https://github.com/facebook/react-native/pull/35443 we stopped running CI in Node 14 - this follows up by formally making Node 16 the minimum supported version ahead of the 0.72 cut.
Node 14 [ends maintenance releases in April](https://github.com/nodejs/release#release-schedule), and bumping this minimum will allow other associated Node JS tools (CLI, Metro, Jest) to reduce their support burden.
## Insert `engines` into `template/package.json`
The constraint at `react-native/package.json#engines` ensures the minimum at install/init time, with package managers providing an actionable error or warning if the constraint is not met. However, it doesn't help guide users to a supported version if on an existing project they run (e.g.) `yarn start`.
Adding a constraint to the template helps prevent accidental use of an older version, as well as providing a clear reference for the current minimum.
Insertion of `engines` below existing `package.json` fields is consistent with [`sort-package-json`](https://github.com/keithamus/sort-package-json/blob/main/defaultRules.md) and [`prettier-package-json`](https://github.com/cameronhunter/prettier-package-json/blob/main/src/defaultOptions.ts) - and keeps it out of the way of fields RN developers are likely to be more concerned about.
## Docs PR
https://github.com/facebook/react-native-website/pull/3580
## Changelog:
[General][Breaking] Bump minimum Node JS version to 16
Reviewed By: jacdebug
Differential Revision: D43436883
fbshipit-source-id: 0b369487fe44fe777e6fedc2299973a5fddd06b2
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36208
IMO, there's no value in having `.node-version` files either in the repository or the template.
I don't believe it's standard practice, the support from tooling is patchy (at least `nvm` [ignores it](https://github.com/nvm-sh/nvm/issues/794), and Node is often used without a version manager), and it's unnecessarily restrictive when it is actually enforced. In every other case, it's potentially misleading noise.
Libraries should use `package.json#engines` to specify their Node JS compatibility ranges, as indeed `react-native` [already does](1629b9f0a1/package.json (L10)). React Native users may wish to add one to their own projects according to their own setup or team, but we shouldn't confuse the issue by including an arbitrary one in the template.
Changelog:
[General][Removed] Remove `.node_version` from app template.
Reviewed By: jacdebug, blakef
Differential Revision: D43421085
fbshipit-source-id: 37a9b0fb7701f06fffb867dbc7ecac479b4d9c95
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36215
When we introduced the RCTAppDelegate library, we prepared some template methods for the user to customise their views.
However, after they customized their view, we were chaing the background color to match the system background. This would actually override the background color they set in their own customisation step.
This change make sure that we set the background color before they apply their customisations. In this way, we set the background color and, if they want, they can change it and that changw would be honoured.
This change also fixes [this issue](https://github.com/facebook/react-native/issues/35937)
## Changelog
[iOS][Fixed] - Honour background color customisation in RCTAppDelegate
Reviewed By: cortinico
Differential Revision: D43435946
fbshipit-source-id: cdbdbd5b07082ae7843a4dab352dd1195c69e036
Summary:
When building from source, the PrivateReactExtension is getting no defaults (or missing defaults).
Specifically root should point to ../../ (as the build from source will originate
from `./node_modules/react-native`).
Without that root specified, all the subsequent paths are broken,
specifically, the default being `../` causes the codegen to be searched inside:
```
project/node_modules/node_modules/react-native/codegen
```
which is broken
Changelog:
[Internal] [Changed] - RNGP - Fix defaults for PrivateReactExtension
Reviewed By: cipolleschi
Differential Revision: D43435590
fbshipit-source-id: 2ed5e26c1d63fd808fc2d559ea83d6d39d106ff6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36194
This change is the iOS equivalent of D43344120 (8486e191a1), but for iOS.
## Changelog:
[iOS][Fixed] - Turn on NDEBUG when pods are installed for production.
Reviewed By: cortinico
Differential Revision: D43388881
fbshipit-source-id: 5c16d3d7b4265e4ee2f265a5f992cffee30f3887
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36197
[Changelog][Internal]
This turns NativePerformance* module dependencies into "TurboModule plugins", which allows for more streamlined client integration (as it makes them register automatically once the dependency is there).
Reviewed By: rubennorte
Differential Revision: D43353204
fbshipit-source-id: 01d0089750a4873088dc4aefe34fd48693ee9791
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36201
[Changelog][Internal]
Guard call to the C++ ReadableNAtiveMap.importValues with a lock.
Note that all the occurrences in this class (together with importTypes) already were protected by a lock, except of this one, which with the very high chance caused crashes in T145271136.
My corresponding comment from the task, for justification:
> If callstack to be trusted, the crash happens on the C++ side, in ReadableNativeMap::importValues().
It throws ArrayIndexOutOfBoundsException, which, looking at the code, seems to be only possible due to a corrupted data or race conditions.
> Now, looking at the Java side of ReadableNativeMap, and the particular call site... it's very dodgy, since all other occurrences of calling to native importTypes/importValues are guarded by locks, but the one crashing isn't.
NOTE: A couple of `importKeys()` instances appears to suffer from the same problem as well.
Reviewed By: javache
Differential Revision: D43398416
fbshipit-source-id: 0402de5dc723a2fba7d0247c8ad4aeff150d8340
Summary:
changelog: [iOS][Fixed] Fix a crash when reloading JS bundle
Do not crash if self is nil.
Reviewed By: blakef
Differential Revision: D43352039
fbshipit-source-id: dd53677ca152d4021e43ed8d0f1b51c071ca3365
Summary:
This updates all the package usages after the recent bump on main.
## Changelog
[INTERNAL] - Update all package usage on main after a bump
Pull Request resolved: https://github.com/facebook/react-native/pull/36200
Test Plan: Relying on CI
Reviewed By: hoxyq
Differential Revision: D43397084
Pulled By: cortinico
fbshipit-source-id: 06a13772a627f812d7d39931f32071fa3eaa59f9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36192
Builds are failing on CI because brew bails out when it tries installing Python 3.1. The image already has an existing version of Python 3, which we should overwrite.
{F876436464}
This seems to be a known issue [1] with Brew. In this case it seems safe to overwrite.
Changelog:
[General][Changed] - Brew overwrites system Python 3.
[1] https://github.com/actions/setup-python/issues/577#issuecomment-1431468702
Reviewed By: cipolleschi
Differential Revision: D43391941
fbshipit-source-id: 9b0cb234eeb0b7473b17b5ebfa6ed12c6448760f
Kyaw Thura
Xin Chen
Samuel Susla
Olga Zinoveva
Genki Kondo
Steve Alves-Blyt
Nick Gerleman
Mitch Powell
Riccardo Cipolleschi
Nicola Corti
Saad Najmi
Pieter De Baets
Ruslan Shestopalyuk
Tarun Chauhan
Ruslan Lesiutin
ArthurAssuncao
Rob Hogan
Pieter Vanderwerff
Blake Friedman