Summary: Changelog: [Internal] - Remove picker from Modal example in RNTester in prep for deprecating Picker from RN
Reviewed By: kacieb
Differential Revision: D29082452
fbshipit-source-id: 01ee5ae2d0978721f7229d824f23cfbccfaf2813
Summary: Changelog: [Internal] - Remove Picker from accessibility example as a first step to deprecate Picker from react-native
Reviewed By: kacieb
Differential Revision: D29082453
fbshipit-source-id: d1d6eb0514453126351b41c2ca5d72d2c81f5dc9
Summary:
This feature is still causing some number of crashes, though prod impact is not yet determined. For safety I'm adding a feature flag so we can disable this if necessary.
Changelog: [internal]
Reviewed By: kacieb
Differential Revision: D29117957
fbshipit-source-id: 3b19bac9dd00735f51f5c9cba606378b2a62975e
Summary:
In the refactor in D28933824 (https://github.com/facebook/react-native/commit/6b601db8b83337415113a123d780fb64aa67af42), an early return was accidentally deleted. This causes incorrect measurements to be returned, which can break a few things including Text Inline Views.
Changelog: [internal]
Reviewed By: mdvacca
Differential Revision: D29122235
fbshipit-source-id: 76c8991132e22cd4e0fc1c277447c4dba751adfb
Summary:
Changelog: [internal]
RuntimeScheduler can be accessed before any Fabric surface is rendered. Therefore, it needs to be created and installed in the runtime at the start up of the runtime.
Reviewed By: JoshuaGross
Differential Revision: D29091848
fbshipit-source-id: ff75ef8c4882550795e5d4a258355b651cb0e637
Summary:
If function name is an empty string then it would fail to parse the line. And not only that, it would cause the entire stack to be lost. This fixes the issue by replacing `.+?` with `.*?`.
For example this line fails to parse:
```
at global (:2:4)
```
Changelog:
[General][Fixed] - Fixed bug parsing hermes call stacks when the file name is empty
Reviewed By: yungsters
Differential Revision: D29063192
fbshipit-source-id: 604e457af51f852fe547e6424283631ae148897d
Summary:
Changelog: [internal]
Using keyboard's autocomplete did not insert space at the end of the word.
Reviewed By: fkgozali
Differential Revision: D29085654
fbshipit-source-id: 35fee726ea7d2030fdfa64300e045a303ea98ce9
Summary:
Changelog: [internal]
To prevent wrong TextInput becoming first responder, force a resign when preparing for a reuse.
Reviewed By: JoshuaGross
Differential Revision: D29085923
fbshipit-source-id: 246cdf0628f914c3928cc9c7499d029b77684f2c
Summary:
Rewrites `ReactNativeStyleAttributes` so that it is statically defined.
This means it will no longer require a handful of modules that defines `prop-types` only to use their keys.
Functionally, this should be equivalent to what was there before.
Changelog:
[Internal]
Reviewed By: TheSavior
Differential Revision: D29019308
fbshipit-source-id: 47f85a8c7703a133c68c20c7f3e14e1026ce4ff2
Summary:
Simplifies the Flow type for `ReactNativeStyleAttributes`, an internal module.
Changelog:
[Internal]
Reviewed By: TheSavior
Differential Revision: D29019311
fbshipit-source-id: cf95dac4b8c2261812cc1d753255dfb905540759
Summary:
Deletes `StyleSheetValidation` because it is `prop-types` in disguise.
Changelog:
[General][Removed] - `StyleSheet.create` will no longer do DEV-time validation.
Reviewed By: TheSavior
Differential Revision: D29019310
fbshipit-source-id: bfe886d8dc09a1aa8dac4a73bfd62f481e3eb9e9
Summary:
Removes the unnecessary dependency from `DeprecatedTextInputPropTypes` on `Text`. Just use `DeprecatedTextPropTypes` directly.
Changelog:
[Internal]
Reviewed By: TheSavior
Differential Revision: D29017596
fbshipit-source-id: b816c2261bf473e02473d84984cfb3d5a63ec8c1
Summary:
Moves `ImagePropTypes` out of `Image.android.js` in preparation for some cleanup.
Changelog:
[Internal]
Reviewed By: TheSavior
Differential Revision: D29017076
fbshipit-source-id: e7d3d6533f69dc2c54e7c25e215648d7c7ff1840
Summary:
This pre-suppresses the 154 error diff ahead of its release, since it is large.
Changelog: [Internal]
Reviewed By: samwgoldman
Differential Revision: D29065246
fbshipit-source-id: f418041305a46df410dcbe3d9a4db81a61ac7014
Summary:
Adding runtime type information adds greatly to the binary size, so react-native-windows builds without it. But some parts of the fabric code currently uses dynamic_cast, which means to use fabric we have to build with RTTI turned on. This PR removes the usages of dynamic_cast that are hit in release builds, which should allow react-native-windows to turn off RTTI in release builds.
Required for: https://github.com/microsoft/react-native-windows/issues/7981
One thing to note, the comment in ShadowNodeTraits indicates that core was reserving the first 16 bits. I'm adding two more. Is that ok? Should core be reserving more for future use?
## 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
-->
[Internal] [Fixed] - Remove uses of dynamic_cast in release builds
Pull Request resolved: https://github.com/facebook/react-native/pull/31694
Test Plan:
Verified that I can build react-native-windows with Fabric in release, without RTTI.
Boot / clicked around in RNW RNTester
Reviewed By: sammy-SC
Differential Revision: D29040383
Pulled By: JoshuaGross
fbshipit-source-id: e49286e59c4ba54faf0b4de5e244dfa1f7c3f193
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/31675
As requested in parent diff, moved the Android dep bumps into a separate diff.
## Changelog
[general][changed] - [Android] Update Flipper to 0.93.0
Reviewed By: mdvacca, ShikaSD
Differential Revision: D28688486
fbshipit-source-id: c3a8e0edeebdabd490b2885497e261f64bdab4bd
Summary:
This PR bumps Fresco to 2.5.0, which is first version on MavenCentral since jCenter announcement.
## Changelog
[Android] [Changed] - Bump Fresco to 2.5.0
Pull Request resolved: https://github.com/facebook/react-native/pull/31699
Test Plan: CI is green
Reviewed By: TheSavior
Differential Revision: D29031847
Pulled By: passy
fbshipit-source-id: 486ffbf5461d07d736c0ebe17c0c7726937db344
Summary:
In the CONTRIBUTING.md file, when a user clicks on the hyperlink for either issues(line 33) or pull requests(line 34), they are directed to a filler page which has them click on an additional hyperlink to take them to the page they are looking for. The only thing present on the filler page is a hyperlink. So, in terms of usability, it does not make sense to have users go through an extra click to get to the page they want. I have changed the hyperlinks of Issues(line 33) and Pull Requests(line 34) to takes users directly to Triaging GitHub Issues and Managing-Pull-Requests
## Changelog
[GENERAL][CHANGED]-See lines 33 and 34 of https://github.com/facebook/react-native/blob/master/CONTRIBUTING.md
Pull Request resolved: https://github.com/facebook/react-native/pull/31696
Test Plan: First, I ensured that the code lints and the test suite passes. For testing the links, I opened my fork in GitHub and opened the CONTRIBUTING.md file. I clicked on both hyperlinks to ensure that they both worked properly. No tests were added for this code.
Reviewed By: lunaleaps
Differential Revision: D29046728
Pulled By: TheSavior
fbshipit-source-id: 99ec989938660102aefa07862542dc9a007359ce
Summary:
As title
Changelog:
[General][Changed] Update Image.[android|ios].js to use import from instead of require
Reviewed By: TheSavior, yungsters
Differential Revision: D29003824
fbshipit-source-id: 0f98c730b1bd9cb581d2fcf6f4c0e911bb8c24b5
Summary:
added .hprof file is generated when building a release apk and it's size is > 300 MB, and we don't want it to be in the repo
## Changelog
[General] [Changed] - Remove .hprof
Pull Request resolved: https://github.com/facebook/react-native/pull/31679
Reviewed By: yungsters
Differential Revision: D28967470
Pulled By: PeteTheHeat
fbshipit-source-id: 521f653428ebdd2a33fb251ce18c4faada53bf27
Summary:
## Rationale
The public methods of PackagerCommandListener should not be a part of the public API of DevSupportManagerBase. It's cleaner to just create a new PackagerCommandListener object inline, when we need it. This way, there're are less methods to think about when reasoning about the public API of DevSupportManagerBase.
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D29006835
fbshipit-source-id: 0eea86c22e7d676c94d29b240a1f39955d8216ab
Summary:
## Rationale
This reduces the surface area of DevSupportManager's public API.
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D29006836
fbshipit-source-id: 579364f6c556b8588f3b6bac79df3deb244a92e5
Summary:
## Rationale
This DevSupportManagerBase constructor isn't used anywhere, aside from VeniceDevSupportManager. Even in VeniceDevSupportManager, we should use the more specific constructor, because it informs readers of the class what specifically is being nullified in the base class. So, this diff gets rid of the smaller arity constructor.
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D29004542
fbshipit-source-id: 74e20db93cf1871a364bf228dc089cd7d124297f
Summary:
## Rationale
DevSupportManagerBase.handleReloadJS() implements reloads for the bridge. Therefore, it's best to move this method to BridgeDevSupportManager.
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D29004541
fbshipit-source-id: f77244e9c44cd442e7e0ab2845f78d699b143e66
Summary:
## Rationale
Throughout DevSupportManagerBase, we show/hide the DevLoadingView and simultaneously write to the `mDevLoadingViewVisible` boolean. This diff pulls all those boolean writes into methods, so that subclasses of DevSupportManagerBase can show/hide the DevLoadingView without accessing the boolean directly.
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D29004062
fbshipit-source-id: d54d79701e31f9ac8d1d1d44019199718fe1c8c0
Summary:
## Rationale
DevSupportManagerBase.loadSplitBundleFromServer() uses the bridge. So, it's best to move it to DevSupportManagerBase.
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D29004064
fbshipit-source-id: 9acfb769d57a44ee4871e1997ff0950c3d66b757
Summary:
PreAllocation currently always happens at revision 0 (after ShadowNode creation), and all CREATE mutations are triggered for ShadowNodes at revision 1 or higher (since CREATE mutations are generated by the differ, it means that all ShadowNodes have revision 1 or higher when CompleteRoot is called). This means that between PreAllocation and CREATE, we /always/ expect at least one clone.
It is possible for a node to be "non-view-forming" at revision 0, causing view preallocation to be skipped, and "view-forming" at revision 1 (causing the CREATE mutation to be thrown away, since all CREATE mutations of revision 0 or 1 are thrown away). This causes a crash. It is extremely marginal, but there are repros in the wild.
Thus, I'm introducing one new UIManager and Scheduler delegate method that allows the mounting layer to be notified of clones. If a clone from rev 0->1 results in a node going from non-view-forming to view-forming, we can preallocate then, as well.
This resolves this crash, and allows us to keep experimenting safely with this View PreAllocation optimization. I believe all edge-cases are accounted for.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D29043426
fbshipit-source-id: dff11d3140ded1cbb02a5518a3aeb52dc812cc50
Summary:
Original PR: https://github.com/facebook/react-native/pull/31258
## Imported PR from Github:
This is a continuation of https://github.com/facebook/react-native/pull/29683. I've talked to danilobuerger who does not intend on continue work on it and is OK with me picking up where he left. This PR is identical besides adding a test case in the RN Tester app as requested in the original PR.
In summary it gives iOS feature parity with Android in the sense that one can use user-defined native colors, something even the docs claim is possible. It's useful as it enables accessibility features such as high contrast colors and makes implementing dark mode simple. For an example on how it can be used, see https://github.com/klarna-incubator/platform-colors
## Changelog
[iOS] [Added] - Allow PlatformColor to return user-defined named asset color
Pull Request resolved: https://github.com/facebook/react-native/pull/31258
Test Plan: Test case added to RN Tester.
Reviewed By: sammy-SC
Differential Revision: D28803206
Pulled By: p-sun
fbshipit-source-id: e0f0690274799bd2d09c9f9d1a6a95ac0f979498
Summary:
https://github.com/facebook/react-native/issues/31345
The issue to` android/app/src/main/res/values/styles.xml.`
In the base application theme, there is an explicitly added item
`<item name="android:textColor">#000000</item>`
This leads the `textColor` of the app to be black even though the theme is actually DayNight.
A permanent fix would be to not have this item added by default when creating a new project, as it is buggy behavior
## Changelog
[General] [removed] - line `<item name="android:textColor">#000000</item>` in this file `android/app/src/main/res/values/styles.xml `for the inital setup
Pull Request resolved: https://github.com/facebook/react-native/pull/31487
Test Plan: Removing this has fixed the issue for me.
Reviewed By: yungsters
Differential Revision: D28966678
Pulled By: ShikaSD
fbshipit-source-id: 57c6b4b7b5f11847ea6e611c7567c0c03133c79d
Summary:
This PR sets project wide Kotlin version to 1.4.21, supported in Buck https://github.com/facebook/buck/tree/dev/third-party/java/kotlin.
We had to specify version for both kotlin-dsl and kotlin('jvm') plugins to remove version mismatch warnings in **react-native-gradle-plugin**. Also I expect more Kotlin code in RN, so instead of specifying version for each sub-project it's better to have project wide setting.
We don't need to load Kotlin in react-native-gradle-plugin because Kotlin is available RN project wide.
## Changelog
[Internal] [Changed] - Project wide Kotlin version set to 1.4.21
Pull Request resolved: https://github.com/facebook/react-native/pull/31645
Test Plan: Everything works as expected, no visible change for developers.
Reviewed By: yungsters
Differential Revision: D28991440
Pulled By: ShikaSD
fbshipit-source-id: 971fa6f50c12d916a56d0dcde7c65299496fb68a
Summary:
In T92179998, there is a crash when an EventEmitterWrapper is deallocated after the JS VM is torn down, and the EventEmitterWrapper tries to free its JSI::Pointer reference (double-free).
To make sure this happens less/not at all, free EventEmitterWrappers on ViewState when a view is deleted, instead of waiting for all of RN to be torn down.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D29020768
fbshipit-source-id: 9d72a23bc9966992ef56c1e3ee523405d4333194
Summary:
Changes React Native CI (both Sandcastle and Circle CI) to use `OS=latest` instead of a hardcoded version number.
This reduces the number of hardcoded configurations needed to be updated for new Xcode versions by one.
Changelog:
[Internal]
Reviewed By: fkgozali
Differential Revision: D29013193
fbshipit-source-id: 3c081de1b74a130867b2a599d3e7333846c96cf7
Summary:
Fixes https://github.com/facebook/react-native/issues/30502.
This PR fixes a crash caused by a `NullPointerException` when updating the `snapToOffsets` property.
I noticed this crash on production, you'll find the stack trace below.
Cause: `snapToOffsets` is annotated `Nullable` but there are no nullability check before calling `snapToOffsets.size()`.
## Changelog
[Android] [Fixed] - Fixed a crash when updating `snapToOffsets` to a null value
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://github.com/facebook/react-native/wiki/Changelog
-->
Pull Request resolved: https://github.com/facebook/react-native/pull/31681
Test Plan:
Passing `snapToOffsets={undefined}` to a `FlatList` used to crash on Android. Not anymore.
## Stacktrace
```
com.facebook.react.bridge.JSApplicationIllegalArgumentException: Error while updating property 'snapToOffsets' of a view managed by: RCTScrollView
at com.facebook.react.uimanager.ViewManagersPropertyCache$PropSetter.updateViewProp(ViewManagersPropertyCache.java:102)
at com.facebook.react.uimanager.ViewManagerPropertyUpdater$FallbackViewManagerSetter.setProperty(ViewManagerPropertyUpdater.java:136)
at com.facebook.react.uimanager.ViewManagerPropertyUpdater.updateProps(ViewManagerPropertyUpdater.java:56)
at com.facebook.react.uimanager.ViewManager.updateProperties(ViewManager.java:49)
at com.facebook.react.uimanager.NativeViewHierarchyManager.updateProperties(NativeViewHierarchyManager.java:143)
at com.facebook.react.uimanager.UIViewOperationQueue$UpdatePropertiesOperation.execute(UIViewOperationQueue.java:93)
at com.facebook.react.uimanager.UIViewOperationQueue$1.run(UIViewOperationQueue.java:908)
at com.facebook.react.uimanager.UIViewOperationQueue.flushPendingBatches(UIViewOperationQueue.java:1019)
at com.facebook.react.uimanager.UIViewOperationQueue.access$2600(UIViewOperationQueue.java:47)
at com.facebook.react.uimanager.UIViewOperationQueue$DispatchUIFrameCallback.doFrameGuarded(UIViewOperationQueue.java:1079)
at com.facebook.react.uimanager.GuardedFrameCallback.doFrame(GuardedFrameCallback.java:29)
at com.facebook.react.modules.core.ReactChoreographer$ReactChoreographerDispatcher.doFrame(ReactChoreographer.java:175)
at com.facebook.react.modules.core.ChoreographerCompat$FrameCallback$1.doFrame(ChoreographerCompat.java:85)
at android.view.Choreographer$CallbackRecord.run(Choreographer.java:1008)
at android.view.Choreographer.doCallbacks(Choreographer.java:809)
at android.view.Choreographer.doFrame(Choreographer.java:740)
at android.view.Choreographer$FrameDisplayEventReceiver.run(Choreographer.java:995)
at android.os.Handler.handleCallback(Handler.java:938)
at android.os.Handler.dispatchMessage(Handler.java:99)
at android.os.Looper.loop(Looper.java:246)
at android.app.ActivityThread.main(ActivityThread.java:8512)
at java.lang.reflect.Method.invoke(Method.java:-2)
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:602)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1130)
Caused by: java.lang.reflect.InvocationTargetException
at java.lang.reflect.Method.invoke(Method.java:-2)
at com.facebook.react.uimanager.ViewManagersPropertyCache$PropSetter.updateViewProp(ViewManagersPropertyCache.java:87)
at com.facebook.react.uimanager.ViewManagerPropertyUpdater$FallbackViewManagerSetter.setProperty(ViewManagerPropertyUpdater.java:136)
at com.facebook.react.uimanager.ViewManagerPropertyUpdater.updateProps(ViewManagerPropertyUpdater.java:56)
at com.facebook.react.uimanager.ViewManager.updateProperties(ViewManager.java:49)
at com.facebook.react.uimanager.NativeViewHierarchyManager.updateProperties(NativeViewHierarchyManager.java:143)
at com.facebook.react.uimanager.UIViewOperationQueue$UpdatePropertiesOperation.execute(UIViewOperationQueue.java:93)
at com.facebook.react.uimanager.UIViewOperationQueue$1.run(UIViewOperationQueue.java:908)
at com.facebook.react.uimanager.UIViewOperationQueue.flushPendingBatches(UIViewOperationQueue.java:1019)
at com.facebook.react.uimanager.UIViewOperationQueue.access$2600(UIViewOperationQueue.java:47)
at com.facebook.react.uimanager.UIViewOperationQueue$DispatchUIFrameCallback.doFrameGuarded(UIViewOperationQueue.java:1079)
at com.facebook.react.uimanager.GuardedFrameCallback.doFrame(GuardedFrameCallback.java:29)
at com.facebook.react.modules.core.ReactChoreographer$ReactChoreographerDispatcher.doFrame(ReactChoreographer.java:175)
at com.facebook.react.modules.core.ChoreographerCompat$FrameCallback$1.doFrame(ChoreographerCompat.java:85)
at android.view.Choreographer$CallbackRecord.run(Choreographer.java:1008)
at android.view.Choreographer.doCallbacks(Choreographer.java:809)
at android.view.Choreographer.doFrame(Choreographer.java:740)
at android.view.Choreographer$FrameDisplayEventReceiver.run(Choreographer.java:995)
at android.os.Handler.handleCallback(Handler.java:938)
at android.os.Handler.dispatchMessage(Handler.java:99)
at android.os.Looper.loop(Looper.java:246)
at android.app.ActivityThread.main(ActivityThread.java:8512)
at java.lang.reflect.Method.invoke(Method.java:-2)
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:602)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1130)
Caused by: java.lang.NullPointerException: Attempt to invoke interface method 'int com.facebook.react.bridge.ReadableArray.size()' on a null object reference
at com.facebook.react.views.scroll.ReactScrollViewManager.setSnapToOffsets(ReactScrollViewManager.java:107)
at java.lang.reflect.Method.invoke(Method.java:-2)
at com.facebook.react.uimanager.ViewManagersPropertyCache$PropSetter.updateViewProp(ViewManagersPropertyCache.java:87)
at com.facebook.react.uimanager.ViewManagerPropertyUpdater$FallbackViewManagerSetter.setProperty(ViewManagerPropertyUpdater.java:136)
at com.facebook.react.uimanager.ViewManagerPropertyUpdater.updateProps(ViewManagerPropertyUpdater.java:56)
at com.facebook.react.uimanager.ViewManager.updateProperties(ViewManager.java:49)
at com.facebook.react.uimanager.NativeViewHierarchyManager.updateProperties(NativeViewHierarchyManager.java:143)
at com.facebook.react.uimanager.UIViewOperationQueue$UpdatePropertiesOperation.execute(UIViewOperationQueue.java:93)
at com.facebook.react.uimanager.UIViewOperationQueue$1.run(UIViewOperationQueue.java:908)
at com.facebook.react.uimanager.UIViewOperationQueue.flushPendingBatches(UIViewOperationQueue.java:1019)
at com.facebook.react.uimanager.UIViewOperationQueue.access$2600(UIViewOperationQueue.java:47)
at com.facebook.react.uimanager.UIViewOperationQueue$DispatchUIFrameCallback.doFrameGuarded(UIViewOperationQueue.java:1079)
at com.facebook.react.uimanager.GuardedFrameCallback.doFrame(GuardedFrameCallback.java:29)
at com.facebook.react.modules.core.ReactChoreographer$ReactChoreographerDispatcher.doFrame(ReactChoreographer.java:175)
at com.facebook.react.modules.core.ChoreographerCompat$FrameCallback$1.doFrame(ChoreographerCompat.java:85)
at android.view.Choreographer$CallbackRecord.run(Choreographer.java:1008)
at android.view.Choreographer.doCallbacks(Choreographer.java:809)
at android.view.Choreographer.doFrame(Choreographer.java:740)
at android.view.Choreographer$FrameDisplayEventReceiver.run(Choreographer.java:995)
at android.os.Handler.handleCallback(Handler.java:938)
at android.os.Handler.dispatchMessage(Handler.java:99)
at android.os.Looper.loop(Looper.java:246)
at android.app.ActivityThread.main(ActivityThread.java:8512)
at java.lang.reflect.Method.invoke(Method.java:-2)
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:602)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1130)
```
Reviewed By: ShikaSD
Differential Revision: D28965864
Pulled By: JoshuaGross
fbshipit-source-id: f08f1df371c1892935e1290806cc67d34394203b
Summary:
Changelog:
[Internal] - Replace `useImperativeHandle` usage with new `useMergeRef` which will keep both the forwarded and internal ref handle up to date (in case the instance ever changes). That being said, this change was not motivated in fear of a stale ref but more an intention to show that `useImperativeHandle`'s use case is more about creating a selective API and `useMergeRef` is better suited for publishing ref updates.
Reviewed By: yungsters
Differential Revision: D28950632
fbshipit-source-id: 594afda02693545aab77f24566180c338b58bb8b
Summary:
`jest/create-cache-key-function` should be installed as part of the react-native package since it is used by the jest config. Running jest currently errors unless this package is somehow transitively installed.
## Changelog
[General] [Fixed] - Add missing jest/create-cache-key-function dep root package.json
Pull Request resolved: https://github.com/facebook/react-native/pull/31668
Test Plan: Run jest in a RN app.
Reviewed By: rubennorte
Differential Revision: D28953697
Pulled By: lunaleaps
fbshipit-source-id: a0862ea3b2bc93a72bb4a0f976ef486a66112ec5
Luna Wei
Joshua Gross
Samuel Susla
CodemodService FBSourceClangFormatLinterBot
Martin Sherburn
Tim Yung
Daniel Sainati
Andrew Coates
Michel Weststrate
Dulmandakh
Rui Ying
Justin
Kacie Bawiec
Hamza Jadid
Ramanpreet Nara
Joel Arvidsson
Siddharth Verma
Maxime Bertheau
Janic Duplessis
Nishan Bende