Summary:
… request to local pathname comparator variables to fix issue with other rightward elements of url such as query or fragment entering the comparison and causing 404 errors for key debugging routes.
A change in Chromium appended the query "?for_tabs" to the /json/list request made by Chrome DevTools to find remote debugger targets.
The current comparison in InspectorProxy.js compares the entire node IncomingMessage url field to the local pathname constants. The issue arises as url can also contain the query and fragment portions so the original comparison of "/json/list" === "/json/list" which resolved as true would become "/json/list?for_tabs" === "/json/list" and evaluate to false ultimately resulting in a 404 for the request.
In summary, all these changes/issues caused remote debugging of Hermes code in React Native apps to become unavailable, greatly impacting developer experience.
## Changelog:
[GENERAL] [FIXED] JS Debugging: Fix inspector-proxy to allow for DevTools requests with query strings
Pull Request resolved: https://github.com/facebook/react-native/pull/41005
Reviewed By: NickGerleman
Differential Revision: D50342265
Pulled By: robhogan
fbshipit-source-id: a65f2908f0bea9fc15e1e3e4e6d31a3b9598e81f
Summary:
- ref: https://github.com/reactwg/react-native-releases/discussions/64#discussioncomment-7270126
With react-native@0.73.0-rc.2 and fresco@3.0.0, `dlopen failed: library "libnative-imagetranscoder.so"` error made crash in android. so, I patched fresco version to 3.1.0, so that resolves the crash error according to https://github.com/facebook/fresco/issues/2722#issuecomment-1749333089 this comment.
## 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
-->
[ANDROID] [FIXED] - b1fccb05ccb306005dc7616a4eaaa182b0b1deaf bumped fresco version to 3.1.0.
Pull Request resolved: https://github.com/facebook/react-native/pull/41024
Test Plan: after bumping fresco version, error not occurs.
Reviewed By: cipolleschi
Differential Revision: D50359564
Pulled By: cortinico
fbshipit-source-id: d24caecc057bad4d9c94e378422ab18c106a7ee6
Summary:
Fix https://github.com/facebook/react-native/issues/40560
## Changelog:
[ANDROID] [FIXED] - Ensure that `configureJavaToolChains` is only executed once during configuration
Pull Request resolved: https://github.com/facebook/react-native/pull/40757
Test Plan:
- Create a fresh `react-native@0.73.0-rc.1` project
- Install `react-native-webview`
- Apply [this patch](https://github.com/react-native-webview/react-native-webview/pull/3175/files) for `react-native-webview` (caused by another issue https://github.com/facebook/react-native/issues/40559)
- Edit `android/gradle.properties` and set `newArchEnabled` to true
- Build application
- (Expected) Application fail to build
- Apply this PR
- (Expected) Application build successfully
**Additional explanation:**
According to the implementation of `configureJavaToolChains`, all the subprojects (both the app and the libraries) will have their toolchains setup in one execution of the method. Therefore, it is okay for the method to be invoked only when configuring the plugin for the app.
On the other hand, invoking the method for more than one time will cause the issue stated in https://github.com/facebook/react-native/issues/40560.
Reviewed By: cipolleschi
Differential Revision: D50361871
Pulled By: cortinico
fbshipit-source-id: bd5e18df97988122788d0482dba954e517a0cb5c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41009
This change should fix [#39971](https://github.com/facebook/react-native/issues/39971), computing the relative path from the App path to the pod installation root and using that instead of the absolute path to the `react-native.config.js` file
## Changelog
[Internal] - Stabilize RCTAppDelegate podspec
Reviewed By: cortinico
Differential Revision: D50323710
fbshipit-source-id: e29e62228d08c752e822d7a9ab5b1a2b5dcd6eb4
Summary:
Problem Causes: In ReactViewGroup, there is a conflict between the zIndex attribute and the removeClippedSubviews optimization attribute. When both are used at the same time, the array mDrawingOrderIndices in ViewGroupDrawingOrderHelper that records the rendering order of subviews is not reset when super is called in the updateSubviewClipStatus method to add and remove subviews.
Solution:�Because there are many third-party components that inherit from or depend on ReactViewGroup, all methods for adding and removing subviews in ViewGroup need to be override in ReactViewGroup, and ViewGroupDrawingOrderHelper corresponding to handleAddView and handleRemoveView needs to be called in these methods. And all the precautions for directly calling super to add and remove subviews are changed to calling the overridden method by ReactViewGroup.
Special Note: All addView related methods in ViewGroup will eventually be called to the addView(View child, int index, LayoutParams params) method, except addViewInLayout. Regarding the method of adding subviews, we only need to override addView(View child, int index, LayoutParams params) and addViewInLayout(View child, int index, LayoutParams params,boolean preventRequestLayout) in ReactViewGroup.
## Changelog:
[Android] [Fixed] - Fix the crash in ReactViewGroup of https://github.com/facebook/react-native/issues/30785
Pull Request resolved: https://github.com/facebook/react-native/pull/40859
Reviewed By: NickGerleman
Differential Revision: D50321718
Pulled By: javache
fbshipit-source-id: 7fa7069937b8c2afb9f30dd10554370b1be5d515
Summary:
For a very long time when a promise rejects without an attached catch we get this warning screen without a correct stack trace, only some internal calls to the RN internals.
<img src="https://github.com/facebook/react-native/assets/1634213/75aa7615-ee3e-4229-80d6-1744130de6e5" width="200" />
I created [an issue for discussion](https://github.com/react-native-community/discussions-and-proposals/discussions/718) in the react-native-community repo and we figured out it was only a matter of symbolication. While it cannot be done on release without external packages and source maps, at least while developing we can provide a symbolicated stack-trace so developers can better debug the source of rejected promise.
I got the stack trace symbolicated and the correct code frame. I'm missing some help trying to display it in the warning view but at the very least I can now correctly show the line of the error and log the codeframe to the console.
## Changelog:
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
[GENERAL] [FIXED] - Show correct stack frame on unhandled promise rejections on development mode.
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
Pull Request resolved: https://github.com/facebook/react-native/pull/40914
Test Plan:
I simply created a throwing function on a dummy app, and checked the output of the console and the warning view:
```ts
import React from 'react';
import {SafeAreaView, Text} from 'react-native';
async function throwme() {
throw new Error('UNHANDLED');
}
function App(): JSX.Element {
throwme();
return (
<SafeAreaView>
<Text>Throw test</Text>
</SafeAreaView>
);
}
export default App;
```
Here is the output
<img src="https://github.com/facebook/react-native/assets/1634213/2c100e4d-618e-4143-8d64-4095e8370f4f" width="200" />
Edit: I got the warning window working properly:
<img src="https://github.com/facebook/react-native/assets/1634213/f02a2568-da3e-4daa-8132-e05cbe591737" width="200" />
Reviewed By: yungsters
Differential Revision: D50324344
Pulled By: javache
fbshipit-source-id: 66850312d444cf1ae5333b493222ae0868d47056
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/40941
Events are currently not working for Fabric Interop on Bridgeless. That's because the `BridgelessReactContext` is not checking for interop modules on `getJsModule` calls, so the `InteropEventEmitter` is never returned.
This extends `BridgelessReactContext` so that `InteropEventEmitter` is returned if the Interop Layer is turned on.
Changelog:
[Internal] [Changed] - Make events work for Fabric Interop on Bridgeless
Reviewed By: cipolleschi
Differential Revision: D50266484
fbshipit-source-id: 0188d71bdc7acc8c188d886d45f0258914ad7af7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41003
Following up the deprecation of Flipper in 0.73 and preparing for the removal of Flipper in 0.74, we are removing Flipper integration from the CI.
## Changelog:
[Internal] - Remove the Flipper integration from CI
Reviewed By: dmytrorykun
Differential Revision: D50321335
fbshipit-source-id: 04885d3dbaab9b2834c9461e0580dfbef386244f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41002
Following up the deprecation of Flipper in 0.73 and preparing for the removal of Flipper in 0.74, we are removing Flipper integration from the Codebase.
## Changelog:
[iOS][Breaking] - Remove the Flipper integration
Reviewed By: dmytrorykun
Differential Revision: D50321255
fbshipit-source-id: d2f4488ada7acdbd3687f54db4204ba7f09370af
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/40895
This is a long running debug assert due to a race condition with BE. I have at times wanted to try to add a lock to protect this, and measure impact, but really it will go away when we get rid of BE anyway, and any strategy I have come up with to lock gets hairy quickly.
This change does not impact RN in OSS, where BE is already disabled.
Changelog: [Internal]
Reviewed By: rshest
Differential Revision: D50247680
fbshipit-source-id: d004fc7db24f1f0b7c3ea8756d4678ce41579712
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/40970
This cleans up 9497203957 a bit, after I did some debugging and looking through Android source code.
1. `getRootView()` gives us constant-time access to root hierarchy, and we don't need to do instanceof check once per level. It also, at least in the sample activity I tried, gives us the Window's `LayoutParams`.
2. The root of the hierarchy is documented in code to do what we want. 9497203957
3. Calling `getRootView().getLayoutParams()`, then casting to `WindowManager.LayoutParams`, seems to show up in a lot of other widgets (inc Unity, RoboElectric), as a solution to getting this information. https://github.com/search?q=getRootView%28%29.getLayoutParams%28%29&type=code
This still feels like not a 100% documented contract, so I added an assertion so we can catch if the contract isn't valid somewhere now or in the future, instead of silently breaking keyboard events.
Note that this code only runs on SDK 30+ (Android 11+).
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D50297761
fbshipit-source-id: f97fb6ea1bcdb1b8e8dfcdcc178625efc0bb6b4a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41011
changelog: [internal]
topContentSizeChange should be a direct event. Otherwise it collides with ScrollView's `onContentSizeChange` any may break FlatList
Reviewed By: javache
Differential Revision: D50323281
fbshipit-source-id: dd8713acfdd5158ac8175b8efe5027d06cd0d0a8
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/40968
Enable Explicit API mode warning to let product developers get notified of Explicit API checks (similar to deprecation mechanism). Explicit API mode will be enabled as strict in a future version
more details: https://kotlinlang.org/docs/whatsnew14.html#explicit-api-mode-for-library-authors
changelog: [Android][Changed] Enabling Explicit API warning, this will be changed as Strict in a future version
Reviewed By: cortinico
Differential Revision: D50295069
fbshipit-source-id: 41f7eb823ef8cfb4266dfa2d927f54c7dab9193a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/40929
This diff reduces the footprint that bridgeless is imposing on the new app template. Specifically:
- I've created a `.toReactHost` method that converts a DefaultReactNativeHost to a DefaultReactHost
- I've updated RN Tester to use the same setup as the New App template which reduces code duplication.
I also had to remove a couple of `UnstableReactNativeAPI` as those were bleeding in the new app template.
I don't think we should ask users to opt-in in `UnstableReactNativeAPI` in the New App template itself as
this means that all the apps will get this opt-in.
Instead we should keep it only for specific APIs that we want the users to opt into.
Changelog:
[Internal] [Changed] - Simplify new app template for bridgeless
Reviewed By: cipolleschi, luluwu2032
Differential Revision: D50227693
fbshipit-source-id: e86c54d5156cc27f1f898b43ca89c57d5cf148b8
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/40866
This type doesn't do anything, and we can replace it with a `jsi::Function` inside `UIManagerBinding`.
Changelog: [Internal]
Reviewed By: rubennorte
Differential Revision: D50176084
fbshipit-source-id: 1c782f3e4d212f1d956451fd650d3ed5ed8f0d71
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/40942
The Fabric Interop example for Android is broken. This is due to the Kotlin conversion which moved the `Color.colorToHSV(color, hsv)` statement *after* the HSV array is read so the array is always [0,0,0].
I'm fixing it here.
Changelog:
[Internal] [Changed] - Fix broken Fabric Interop example
Reviewed By: cipolleschi
Differential Revision: D50264766
fbshipit-source-id: 27ae5289408c7c23c667d6d7112437fa7ebe36d5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/40873
Some host platforms may require the LayoutContext for computing the size of text, e.g. to read the pointScaleFactor value. This change passes the LayoutContext to TextLayoutManager so it can be used during text measurement.
Please note, for now, this does not wire any fields from LayoutContext through to the TextMeasureCache, TextLayoutManager::getHostTextStorage, or TextLayoutManager::measureCachedSpannableById (on Android).
## Changelog:
[General] [Internal]
Reviewed By: rshest
Differential Revision: D50227592
fbshipit-source-id: 37ec16a4828c6cef4a1c1f01d144a86dd29dec29
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/40940
Currently the `onIntArrayChanged` event is invoked
only once inside RN Tester. I'm changing the logic to make sure it fires whenever we click "Set Opacity"
Changelog:
[Internal] [Changed] - Make sure onIntArrayChanged is invoked on RN Tester
Reviewed By: mdvacca, dmytrorykun
Differential Revision: D50264765
fbshipit-source-id: 93a60fd1b657c3d8b8182cab6bb7cd4368ac9a42
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41001
I believe this is due to a race condition between VM teardown and callback invocation. Because we were previously retaining the CallbackWrapper across the invokeAsync call, we may potentially have been holding onto the JSI::Function after it was already destroyed.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D50286876
fbshipit-source-id: 1277a9f37166da59ebb2169fe8d5a6fabce82f1b
Summary:
…king root view frame changes
Looking through where this was introduced (https://github.com/facebook/react-native/pull/37649), it seems the notification went from tracking root view size changes to window size changes. However, it was not renamed. I was using it for root view changes in RN-macOS, which.. I guess I'll refactor. Meanwhile, let's update the name?
## Changelog:
[IOS] [CHANGED] - Rename `RCTRootViewFrameDidChangeNotification` as it's not tracking root view frame changes
Pull Request resolved: https://github.com/facebook/react-native/pull/39835
Test Plan: CI should pass
Reviewed By: cipolleschi
Differential Revision: D50173742
Pulled By: javache
fbshipit-source-id: 4651696174c439800984a5e6cf642200bb9c4f3c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/40998
changelog: [Android] Add back interface FabricViewStateManager to unblock 0.73
I incorrectly deleted FabricViewStateManager in D47993140. This is a breaking change even for old architecture. Let's add it back and mark it as deprected so we can remove it later on.
This interface is not used in react-native anymore.
We are removing FabricViewStateManager because it simply wraps StateWrapper and provides no additional anymore.
Reviewed By: cortinico
Differential Revision: D50318633
fbshipit-source-id: aeb1c66c35018e336339616b564dee6f3156b54b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/40943
We should enable antialiasing when it's necessary, as it's an expensive property. Scale and Translate transforms shouldn't enable it.
Source: https://github.com/facebook/react-native/pull/32920
Changelog: [iOS][Changed] Matched behaviour for allowsEdgeAntialiasing to old architecture.
Reviewed By: sammy-SC
Differential Revision: D50270444
fbshipit-source-id: 8a08039c42f8fb855db2ace140124c33f18dc3bc
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/40936
Found a couple of places where we were accidentally copying Props structs. These can be big, so we should avoid doing so.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D50263678
fbshipit-source-id: f60a0370df9b7f3f146988148d5192d3cc32fb4e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/40935
This is scheduled to land in 0.74, so I'm removed the native integration as this is not needed anymore.
The only thing I left is a stub class to ease the migration out of `ReactNativeFlipper`.
Changelog:
[Android] [Removed] - Remove ReactNative/Flipper Integration
Reviewed By: mdvacca, huntie, cipolleschi
Differential Revision: D50259817
fbshipit-source-id: 28427425340896635607202cd78936f6030e78e0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/40862
The last usages of Folly Futures were deleted in D49073914, so we can remove this dependency from React Native.
## Changelog:
[Internal] - remove folly usage in React-hermes
Reviewed By: NickGerleman, cipolleschi
Differential Revision: D50223640
fbshipit-source-id: 792fd7696c1463a81e25dbef7713620486cc94c7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39364
Once ConnectionDemux.* and Registration.* finish migrating to the new Hermes CDPHandler, there aren't any usage of the other stuff left over in inspector-modern. They can be safely removed.
Changelog: [Internal]
Reviewed By: mattbfb
Differential Revision: D49073914
fbshipit-source-id: bc60a3da85a00ac86beeebd098d7c3566a7c56dd
Summary:
Every file in the react-native-github repo should have the right copyright header. This was missed for this file.
Changelog: Internal
Reviewed By: rubennorte
Differential Revision: D50319271
fbshipit-source-id: 77c20fa4d3679eb5573ce61fd1c9cba60386ee21
Summary:
CircleCI is red because verdaccio fails to publish `normalize-colors`.
For some old dependencies, normalize-colors has been published on the official npmjs with the version we needs.
In order to mitigate the RN red ci, we can consume them directly from NPMJS.
As a followup, we created a task to investigate it next week.
## Changelog:
[Internal] - Skip publishing or normalize colors
Pull Request resolved: https://github.com/facebook/react-native/pull/40977
Test Plan:
Tested locally, running verdaccio and simulating CI. It worked.
CircleCI is green
Reviewed By: robhogan
Differential Revision: D50300449
Pulled By: cipolleschi
fbshipit-source-id: 2259b450deff15a117d1de4690bcfe8a9ba7d115
Summary:
To address the root cause of a recurring issue (https://github.com/facebook/react-native/issues/40797, https://github.com/facebook/react-native/issues/39692) where breaking changes to `react-native/normalize-colors` would be pulled into old versions of `deprecated-react-native-prop-types`, we recently change the dependency in the latter to use a semver range (https://github.com/facebook/react-native-deprecated-modules/pull/27, https://github.com/facebook/react-native/pull/40869).
For CI, we generally force `react-native/*` to be resolved only from Verdaccio locally published packages - ie, the current versions at source. The source version (currently `0.74.1`) isn't semver-compatible with `deprecated-react-native-prop-types`'s dependency (`^0.73.0`), so `npm install` was failing in CI with "no package found". We should be getting `0.73.2` from the public registry in this case.
This restores a previous workaround added in https://github.com/facebook/react-native/pull/34571 but not updated since https://github.com/facebook/react-native-deprecated-modules/pull/11 meant the dependency was now on the pluralised package. We have no dependency on the old non-plural package any more.
## Changelog:
[INTERNAL] [FIXED] - CI/Verdaccio: Proxy `react-native/normalize-colors` from NPM for the `deprecated-react-native-prop-types` dependency.
Pull Request resolved: https://github.com/facebook/react-native/pull/40971
Test Plan: CI
Reviewed By: cipolleschi
Differential Revision: D50298291
Pulled By: robhogan
fbshipit-source-id: 4bf6503108335ffa52654346d1874c217071ff91
Summary:
Fixes https://github.com/facebook/react-native/issues/40754
Hi all!
We noticed that our app started to crash after bumping to RN v0.71.13, anyways after a deeper investigation we also found that the crash occurs in the latest version as well.
Crash log:
```
E FATAL EXCEPTION: main
Process: com.nfl.fantasy.core.android.debug, PID: 6034
java.lang.ClassCastException: android.app.ContextImpl cannot be cast to android.app.Activity
at com.facebook.react.ReactRootView$CustomGlobalLayoutListener.getActivity(ReactRootView.java:926)
at com.facebook.react.ReactRootView$CustomGlobalLayoutListener.checkForKeyboardEvents(ReactRootView.java:946)
at com.facebook.react.ReactRootView$CustomGlobalLayoutListener.onGlobalLayout(ReactRootView.java:912)
at android.view.ViewTreeObserver.dispatchOnGlobalLayout(ViewTreeObserver.java:1061)
```
The code which causes ClassCastException is following [here](ea88fbe229/packages/react-native/ReactAndroid/src/main/java/com/facebook/react/ReactRootView.java (L864)).
In this code explicit type conversion to Activity is not safe because it's not guaranteed by the compiler that context will be compatible with Activity type.
The appropriate issue [has been filed](https://github.com/facebook/react-native/issues/40754).
## 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
-->
[ANDROID] [FIXED] - Fixed crash occurring in certain native views when keyboard events are fired.
Pull Request resolved: https://github.com/facebook/react-native/pull/40755
Test Plan:
Tested it manually with the [reference application](https://github.com/kot331107/rnCrashReproducer). Repro steps are as follows:
- Build and run the app on Android
- Tap the button "Open Modal"
- You should see the red popup fragment to the bottom of the screen
- Tap on the text input to open software keyboard
- Expected: it should show the keyboard and no crash happens.
Reviewed By: arushikesarwani94
Differential Revision: D50198424
Pulled By: NickGerleman
fbshipit-source-id: a5a6d86334856f4ffbe818150da5793380da4702
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/40947
This shows up as this.context shows up as 1 sometimes. Let's just hard-code this to 11, to make the test more reliable.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D50253990
fbshipit-source-id: 1da75e5e5f3226676f9af67fc329a70079eed59e
Summary:
Currently, the template has a `buildToolsVersion = '34.0.0'` specified in the top level .gradle file but it's not currently using it.
This is causing the build to fallback to the default version provided by AGP which is 33.x
This is also causing the CI to download buildtools 34.0.0 as they're not in the container (causing network flakyness).
## Changelog:
[INTERNAL] [FIXED] - Make sure template is consuming the right buildToolsVersion
Pull Request resolved: https://github.com/facebook/react-native/pull/40938
Test Plan: CI should be green
Reviewed By: cipolleschi
Differential Revision: D50270482
Pulled By: cortinico
fbshipit-source-id: 09fdc66fe24f1cae760d07e4a2f044793a66cafc
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/40934
The previous `packages/normalize-color` directory name could be confusing, given we have previously published a `react-native/normalize-color` package in addition to the current `react-native/normalize-colors`. After this change, the directory name and `package.json` `"name"` field are aligned.
Changelog: [Internal]
Reviewed By: cortinico, NickGerleman
Differential Revision: D50229030
fbshipit-source-id: 63854140bf61d7d1d3f1270ed05a2ba76f8c5b0f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/40939
Currently some libs on RN 0.73 are broken as the default for Build Config generation changed
from true to false since AGP 8.x. This reverts the behavior to the old flag.
Closes#40791Closes#40559
Changelog:
[Internal] [Changed] - Make sure buildConfig is turned on for all the 3rd party libraries
Reviewed By: mdvacca
Differential Revision: D50270382
fbshipit-source-id: 02dcb031c577f65be2f41d9da0334c1b3d89e4c5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/40869
Bumps DRNPT to v5 - the significant change is that this one depends on `react-native/normalize-color: ^0.73.0`, instead of `*`, so is protected from future breaking changes to that package.
NOTE: We can't safely include `react-native/normalize-color: ^0.74.0` in the dependency range of DRNPT because `0.74.0` isn't a semver-compliant release (0.74 isn't cut yet), so this will pull 0.73.2 from NPM, which is fine. We may need to publish DRNPT@6 if 0.74 final turns out to contain breaking changes (eg, a Node 20 bump).
Changelog:
[General][Fixed] Update `deprecated-react-native-prop-types` to remove fragile transitive `*` dependencies.
Reviewed By: huntie
Differential Revision: D50228564
fbshipit-source-id: 01aafafad40d9a93d00de2b5f45d2796620b9b5d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/40933
This enables us to have lint coverage (and others) for these files. Visibility is none, so it won't be pulled in to anything.
Also removed no-op JSITracing implementation.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D50262377
fbshipit-source-id: 6218c7a79b5c0328bed8472590cff9e92006b86e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/40882
This header has not been used since facebook/react-native#110b191b landed, generalizing the way props map buffers are initialized.
# Changelog
[General][Internal]
Reviewed By: christophpurrer
Differential Revision: D50237390
fbshipit-source-id: f0f532c59c53b1df5d363cfd49f950697df37128
116-7
DeokHyeon Wi
UNIDY2002
Riccardo Cipolleschi
Samuel Susla
huangtaibin
Oscar Franco
Nicola Corti
Pieter De Baets
Alex Hunt
Phillip Pan
Nick Gerleman
Ingrid Wang
David Vacca
Eric Rozell
Saad Najmi
Moti Zilberman
Gijs Weterings
Riccardo Cipolleschi
Rob Hogan
Filipp Mikheev
Yicheng (Jerry) Gong
Arushi Kesarwani
Ramanpreet Nara
Rob Hogan