Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42153
This non functional change unifies Folly version and compiler flag in a single function, so that it would be easier to update it in the future.
## Changelog:
[Internal] - Unify folly version and compiler flags
Reviewed By: cortinico
Differential Revision: D52564771
fbshipit-source-id: 9b4b50560ddee05ce50465b6854666572148cb25
Summary:
Bump folly version to 2024.01.01.00. Actually we need a version newer than v2023.08.14.00 with the https://github.com/facebook/folly/commit/c52d4490bf1e0cf117a71342b427984f9ffc316e fix. That will fix build error on Android:
```
In file included from /Users/kudo/expo/expo/node_modules/react-native-reanimated/android/src/main/cpp/NativeProxy.cpp:3:
In file included from /Users/kudo/.gradle/caches/transforms-3/dd158a7d05d059a173ae31ca6d78ac49/transformed/jetified-react-android-0.74.0-nightly-20240103-0e533f308-SNAPSHOT-debug/prefab/modules/jsi/include/jsi/JSIDynamic.h:10:
In file included from /Users/kudo/.gradle/caches/transforms-3/dd158a7d05d059a173ae31ca6d78ac49/transformed/jetified-react-android-0.74.0-nightly-20240103-0e533f308-SNAPSHOT-debug/prefab/modules/folly_runtime/include/folly/dynamic.h:1310:
In file included from /Users/kudo/.gradle/caches/transforms-3/dd158a7d05d059a173ae31ca6d78ac49/transformed/jetified-react-android-0.74.0-nightly-20240103-0e533f308-SNAPSHOT-debug/prefab/modules/folly_runtime/include/folly/dynamic-inl.h:22:
In file included from /Users/kudo/.gradle/caches/transforms-3/dd158a7d05d059a173ae31ca6d78ac49/transformed/jetified-react-android-0.74.0-nightly-20240103-0e533f308-SNAPSHOT-debug/prefab/modules/folly_runtime/include/folly/Conv.h:124:
In file included from /Users/kudo/.gradle/caches/transforms-3/dd158a7d05d059a173ae31ca6d78ac49/transformed/jetified-react-android-0.74.0-nightly-20240103-0e533f308-SNAPSHOT-debug/prefab/modules/folly_runtime/include/folly/Demangle.h:19:
/Users/kudo/.gradle/caches/transforms-3/dd158a7d05d059a173ae31ca6d78ac49/transformed/jetified-react-android-0.74.0-nightly-20240103-0e533f308-SNAPSHOT-debug/prefab/modules/folly_runtime/include/folly/FBString.h:1721:19: error: no member named 'strong_ordering' in namespace 'std'
return std::strong_ordering::equal;
~~~~~^
/Users/kudo/.gradle/caches/transforms-3/dd158a7d05d059a173ae31ca6d78ac49/transformed/jetified-react-android-0.74.0-nightly-20240103-0e533f308-SNAPSHOT-debug/prefab/modules/folly_runtime/include/folly/FBString.h:1723:19: error: no member named 'strong_ordering' in namespace 'std'
return std::strong_ordering::less;
~~~~~^
/Users/kudo/.gradle/caches/transforms-3/dd158a7d05d059a173ae31ca6d78ac49/transformed/jetified-react-android-0.74.0-nightly-20240103-0e533f308-SNAPSHOT-debug/prefab/modules/folly_runtime/include/folly/FBString.h:1725:19: error: no member named 'strong_ordering' in namespace 'std'
return std::strong_ordering::greater;
~~~~~^
3 errors generated.
```
## Changelog:
[GENERAL] [CHANGED] - Bump folly version to 2024.01.01.00
Pull Request resolved: https://github.com/facebook/react-native/pull/42145
Test Plan: ci passed
Reviewed By: cortinico, cipolleschi
Differential Revision: D52546945
Pulled By: NickGerleman
fbshipit-source-id: 64aacb1d310062dddf987c7b95f10a477e293693
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42019
Removes the following deprecated properties from React Native:
- `Image.propTypes`
- `Text.propTypes`
- `TextInput.propTypes`
- `ColorPropType`
- `EdgeInsetsPropType`
- `PointPropType`
- `ViewPropTypes`
The deprecation history for these prop types is not super obvious, so here is a summary:
- `react@15.5` extracted `prop-types` into a separate package to reflect that not everybody uses them.
- `react-native@0.68` added a deprecation warning to built-in prop types. (https://github.com/facebook/react-native/commit/3f629049ba9773793978cf9093c7a71af15e3e8d)
- `react-native@0.69` removed built-in prop types. (https://github.com/facebook/react-native/commit/3e229f27bc9c7556876ff776abf70147289d544b)
- `react-native@0.71` restored built-in prop types, along with bug fixes to isolate deprecated usage. (https://github.com/facebook/react-native/commit/b966d297245a4c1e2c744cfe571396cfa7e5ffd3)
We believe that by the next public release, enough time will have passed for the community to be able to upgrade without patching React Native or otherwise working around the removal of these deprecated prop types.
**If anyone has trouble identifying the source of a deleted prop types usage, please file an issue so we can help track it down with you.**
Changelog:
[General][Removed] - Removed deprecated prop types
Reviewed By: lunaleaps, NickGerleman
Differential Revision: D52337762
fbshipit-source-id: 9731f7e1dec29f3df535ab75cc50bed001fdfa0b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41700
The type definition of `useMergeRefs` is incorrect, which forces all callsites to use `$FlowFixMe`. This fixes the definition and removes all the `$FlowFixMe`s caused by it.
Changelog: [internal]
Reviewed By: javache
Differential Revision: D51660716
fbshipit-source-id: 4d4d3a72bdca8c409fd1dda59cc2c94113b024bb
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41701
I did a hotfix for this logic in D51618512. This does a small refactor to improve the code (moving more shared code to the hook and avoiding creating a closure unnecessarily in every call to it).
Changelog: [internal]
Reviewed By: javache
Differential Revision: D51660288
fbshipit-source-id: 472836840b19958402bd0de3e2c09c7cec004156
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41679
This fixes a bug in the original implementation of image attached callbacks (still experimental). The problem was that we were unconditionally caching the ref passed to the underlying image component, which meant that whenever users passed new ref setters we wouldn't call them again.
This fixes that by forcing the creation of a new ref value whenever a new ref is passed to the image component.
Changelog: [internal]
Reviewed By: jehartzog
Differential Revision: D51618512
fbshipit-source-id: ac15160c528563c2131e8b3444dea4a6096f20bc
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41577
# Changelog:
[Internal]-
The change is equivalent in terms of API, however this makes it work nicer with C++ codegen and easier to use with a pure C++ implementation of the native module.
Reviewed By: GijsWeterings
Differential Revision: D51493466
fbshipit-source-id: bf9105670ae56a191ab2e6c8cfb794c2fecd4809
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41570
## Changelog:
[Internal] -
This fixes a subtle problem whereas an update to `Image.source` (or `Image.src`) prop on JS side may not end up getting propagated to the C++ side, with New Architecture.
As the result, this can lead to some weird corner cases, whereas e.g. layout doesn't update after the image's size changes.
Differential Revision: D51479305
fbshipit-source-id: 72afb7dfd0ba32f96af4f9a6564b3b8121a597c7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41529
# Changelog:
[Internal]-
The change is equivalent in terms of API, however this makes it work nicer with C++ codegen and easier to use with a pure C++ implementation of the native module.
Reviewed By: christophpurrer
Differential Revision: D51426015
fbshipit-source-id: aae4d91bb93834e1a9c14a21417724a348de0bd7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41525
This creates an experimental mechanism to get notifications when image instances are created anywhere in the app.
This can be useful to set up things like image performance tracking automatically without having to use a custom component and manually access refs from image components.
Changelog: [internal]
Reviewed By: oprisnik
Differential Revision: D49962063
fbshipit-source-id: b991a808aaa723bea98c27812892cfa468f025a6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41359
This change migrates the remaining podspecs to the new functions, so we do not depend on hardcoded values anymore and we can scale the solution to other platforms.
## Context
Last week I helped macOS to work with static framework.
When multiple platforms are specified, frameworks are build in two variants, the iOS and macOS one.
This break all the HEADER_SEARCH_PATHS as now we have to properly specify the base folder from which the search path is generated.
See also [this PR](https://github.com/microsoft/react-native-macos/pull/1967) where I manually make MacOS work with `use_framewroks!`
## Changelog:
[Internal] - Add helper function to create header_search_path
Reviewed By: shwanton
Differential Revision: D51068403
fbshipit-source-id: 4c0455543363ccf4272d5e8590a7c663d9c33e8b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41260
This was introduced some experiments which are no longer relevant.
Changelog: [Internal]
Reviewed By: yungsters
Differential Revision: D50736166
fbshipit-source-id: 7c9ff571112127e6a9e317113c05c30483626076
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41178
Changelog: [Internal]
in my quest to get rid of all synthesized `methodQueue`s, we have `RCTImageStoreManager` which uses this throughout. in this diff, i add a config that uses a queue that is managed by the module itself instead of the one generated by the infra.
Reviewed By: cipolleschi
Differential Revision: D50585904
fbshipit-source-id: a33f8a4844fe3ef861bf1c3a7b87a9ed4b24d13f
Summary:
This is just a type refactoring to make the typing of the `defaultSource` prop of the Image component more explicit and descriptive (using the `ImageRequireSource` type makes it more clear that we can use the require statement to set an image asset as default source) and this is also more consistent with the `source` prop typing.
Currently :
- The typing of default source is `ImageURISource | number | undefined`
- The typing of source is `ImageSourcePropType` which is equal to `ImageURISource | ImageURISource[] | ImageRequireSource` and `ImageRequireSource` is equal to `number`.
In this PR we change the typing of default source to `ImageURISource | ImageRequireSource | undefined` to make more clear that the number of the default source prop refers to the use of the require statement with an asset file.
## Changelog:
[GENERAL] [CHANGED] - use ImageRequireSource instead of number for the defaultSource prop typing of the Image component
Pull Request resolved: https://github.com/facebook/react-native/pull/40801
Test Plan: No one required since it's a small typing refactoring.
Reviewed By: christophpurrer
Differential Revision: D50209922
Pulled By: NickGerleman
fbshipit-source-id: c25f3c6f145f357ff1cb0b1c7b54a19bf1dec824
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/40728
Just improving type safety of a bunch of modules in the `Image` directory.
Changelog: [internal]
Reviewed By: NickGerleman
Differential Revision: D50080136
fbshipit-source-id: cbfb89aa01cad3882aa08a8ba637e561017d5db6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/40730
This way of injecting the decorator is safer and more convenient to have the proper types inferred by Flow in the injected function.
Changelog: [internal]
Reviewed By: NickGerleman
Differential Revision: D50011840
fbshipit-source-id: 760812fc407d3e39fc7601d17488e3f2032a7065
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/40729
This improves the type definition of the `Image` modules (the common module interface, the platform-specific implementations and the shared types module). It makes them `flow strict-local` and explicitly defines the type signature of some functions typed as `any` before.
Changelog: [internal]
Reviewed By: sullenor
Differential Revision: D50014569
fbshipit-source-id: f1eced43edf84c84bbcb10a3a2d2de27e3d5e374
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/40731
The type definitions for `Image` are unnecessarily complicated, and got even more complicated after the changes for the new multiplatform support in Flow.
We had a `Image.js.flow` and a `Image.flow.js` files (which was confusing) and duplicated type definitions in `Image.js.flow`, `Image.android.js` and `Image.ios.js` because all type definitions in the shared module signature must be defined in the platform-specific modules as well.
This moves all type helpers to a new `ImageTypes.js.flow` file, simplifies the common `Image` module interface (to only define the default export type that the platform-specific module must define) and simplifies the Android and iOS specific versions.
As an added benefit, this also improves Flow type coverage by removing a bunch of FlowFixMe comments.
Changelog: [internal]
Reviewed By: mdvacca
Differential Revision: D50011839
fbshipit-source-id: 9da1c0467630bebf73855f5f9f771a2325adbced
Summary:
This bumps folly, to absorb https://github.com/facebook/folly/commit/45fffa629d6bf7321391222d40613d75e8e067d7 which fixes warnings in XCode 15, and NDK 26 (treated as error bc we have better hygiene there). We then bump a little bit further to get past a new warning added, then fixed later.
Need to manually set `FOLLY_HAVE_GETTIME` on Apple because of the silliness described in https://github.com/facebook/folly/issues/1470#issuecomment-1746035194
There is not a combination of Folly, and Android libc++, that has fixes for warnings, but doesn't require the new libc++ in NDK 26. It is expected then that this commit will fail the build, but the next should succeed, and the two must be landed at the same time.
Changelog: [Internal]
Pull Request resolved: https://github.com/facebook/react-native/pull/39798
Reviewed By: fkgozali
Differential Revision: D49897681
Pulled By: NickGerleman
fbshipit-source-id: 52b97ed5b302abf9e27f38dc655207827852dcc3
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39454
1. Build with C++ 20 everywhere.
2. Update folly in OSS build to avoid a warning, and let us opt out of heavy bits required for supporting coroutines (we are still more than a year behind).
3. Update the folly podspec for the new version of folly
4. Update the many, many, copy/pasted header search paths for folly dependencies to be able to resolve fmt, now exposed to folly headers
4. Replaces a deprecated atomic usage with equivalent.
5. Fixes a deprecated implicit capturing `this` by value in lambda (same behavior, added a TODO because it seems sus)
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D49271685
fbshipit-source-id: 16610f7bcd1032d5796cc11f1cfa92a33d8c2593
Summary:
## Summary:
One of the most common diffs we have in React Native macOS is simply extending the `platforms` key Inside every pod spec to include macOS. React Native tvOS does the same to add tvOS. In the future, React Native may support visionOS, at which point we do the same thing again. Let's define a `min_supported_versions` hash that can be overridden at one place that is extensible to more platforms, instead of just specifying `min_ios_version_supported`.
Note: In doing this change, I have set it that `React-Hermes.podspec` doesn't build for macOS anymore. I think this is safe, since anyone using Hermes on macOS was probably using React Native macOS where we already have a diff to add macOS back?
## Changelog:
[IOS] [CHANGED] - Add min_supported_versions helper to cocoa pods scripts
Pull Request resolved: https://github.com/facebook/react-native/pull/39310
Test Plan: CI should pass.
Reviewed By: NickGerleman
Differential Revision: D49014109
Pulled By: dmytrorykun
fbshipit-source-id: d44fc7b750c70cc263a2c89502c022a0db9a4771
Summary:
I've seen that this throws a warning:
```
<ImageBackground source={{ uri: undefined }}>
```
But this is properly working, without a warning, thus, I believe the code is allowing it:
```
<ImageBackground source={isLoading ? undefined : { uri: 'https://....' }}>
```
## Changelog:
[GENERAL] [CHANGED] - Fixed `source` in `Image` type
Pull Request resolved: https://github.com/facebook/react-native/pull/39230
Test Plan: Not necessary. It's just a DOC change
Reviewed By: rshest
Differential Revision: D48939824
Pulled By: NickGerleman
fbshipit-source-id: fca2e07b7b4d4b947e365bb9d82fcf4cea484951
Summary:
From the video below, we can see that the UI thread has dropped many frames, and it would become worse if there are multiple images.
If an image is located in the sandbox of the disk, we cannot load it using `RCTLocalAssetImageLoader` because `RCTLocalAssetImageLoader.requiresScheduling` is set to true, which loads the data on the UI thread and causes main thread stuttering. This will affect libraries such as `react-native-code-push` and others that save images to the sandbox of the disk.
Therefore, we should replace `RCTLocalAssetImageLoader.canLoadImageURL` from `RCTIsLocalAssetURL(url)` to `RCTIsBundleAssetURL(url)`. Similarly, we should rename the entire `RCTLocalAssetImageLoader` file with `RCTBundleAssetImageLoader`, which ignores images in the disk sandbox. And finally these images will be loaded from `NSURLRequest`, and our UI thread will run smoothly again.
https://user-images.githubusercontent.com/20135674/236368418-8933a2c6-549c-40d3-a551-81b492fe41d5.mp4
## 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
-->
[IOS] [Breaking] - Replace `RCTLocalAssetImageLoader` to `RCTBundleAssetImageLoader`
Pull Request resolved: https://github.com/facebook/react-native/pull/37232
Test Plan:
Test Code:
```javascript
constructor(props) {
super(props)
this.state = {
bundle_image: require('./large_image.png'),
sandbox_image: '',
source: null,
isLoading: false,
}
}
render() {
console.log('render', this.state)
return (
<View style={{ flex: 1, padding: 50, backgroundColor: 'white'}}>
<View style={{ flexDirection: 'row', alignItems: 'center', height: 70}}>
{
[{ title: 'Save Image To SandBox', onPress: () => {
let image = Image.resolveAssetSource(this.state.bundle_image)
console.log(image.uri)
this.setState({ isLoading: true })
RNFetchBlob.config({ fileCache: true, appendExt: "png" }).fetch("GET", image.uri).then(response => {
let path = response.path()
path = /^file:\/\//.test(path) ? path : 'file://' + path
console.log(path)
this.state.sandbox_image = path
}).finally(() => this.setState({ isLoading: false }))
}}, { title: 'Load From SandBox', onPress: () => {
this.setState({ source: { uri: this.state.sandbox_image } })
}}, { title: 'Clear', onPress: () => {
this.setState({
source: null,
isLoading: false
})
}}, { title: 'Load From Bundle', onPress: () => {
this.setState({ source: this.state.bundle_image })
}}].map((item, index) => {
return (
<Pressable
key={index}
style={{ height: '100%', justifyContent: 'center', flex: 1, borderWidth: 1, borderColor: 'black', marginLeft: index > 0 ? 15 : 0 }}
onPress={item.onPress}
>
<Text style={{ textAlign: 'center' }}>{item.title}</Text>
</Pressable>
)
})
}
</View>
<ActivityIndicator style={{ marginTop: 10 }} animating={this.state.isLoading} />
<Image
key={`${this.state.source}`}
style={{ marginTop: 20, width: 200, height: 200 }}
source={this.state.source}
onProgress={({ nativeEvent }) => console.log(nativeEvent)}
onLoadStart={() => this.setState({ isLoading: true })}
onLoadEnd={() => this.setState({ isLoading: false })}
/>
</View>
)
}
```
It needs to be tested in three environments: [Simulator_Debug, RealDevice_Debug, RealDevice_Release]
1. Open `Perf Monitor` (RealDevice_Release can be skipped)
2. Click `Save Image to SandBox`
3. Wait for the loading to end and click `Load From SandBox`
4. Verify that the image can be loaded successfully
5. Verify that the `UI thread` keeps `60 FPS` (RealDevice_Release can be skipped)
6. Click `Clear`
7. Repeat steps [3, 4, 5, 6] several times
8. Click `Load From Bundle` to verify that the bundle image can be loaded successfully
Simulator_Debug
https://user-images.githubusercontent.com/20135674/236369344-ee1b8ff1-2d49-49f3-a322-d973f4adf3e7.mp4
RealDevice_Debug
https://user-images.githubusercontent.com/20135674/236369356-fe440b2b-f72a-49be-b63c-b4bf709dac8c.mp4
RealDevice_Release
https://user-images.githubusercontent.com/20135674/236369365-8a6a5c2f-09ad-4c90-b6bd-41e8a5e3aa7f.mp4
Reviewed By: rshest
Differential Revision: D46441513
Pulled By: dmytrorykun
fbshipit-source-id: 652febd4147dbff6c1ceef03d84ce125b8c66770
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/37614
changelog: [internal]
We do not control what `vImageBoxConvolve_ARGB8888` returns, it may return 0. If it does return 0, we will allocate memory chunk of size 0. Yes, malloc will let you do that. Well, it depends on the implementation, but according to the spec it is legal. The only requirement is to by able to call free on that without crash.
If `vImageBoxConvolve_ARGB8888` does return 0 and we allocate memory of size 0. Call to `vImageBoxConvolve_ARGB8888` with tempBuffer of size 0 will lead to a crash.
[The documentation](https://developer.apple.com/documentation/accelerate/1515945-vimageboxconvolve_argb8888#discussion) for `vImageBoxConvolve_ARGB8888` and tempBuffer states:
> To determine the minimum size for the temporary buffer, the first time you call this function pass the kvImageGetTempBufferSize flag. Pass the same values for all other parameters that you intend to use in for the second call. The function returns the required minimum size, which **should be a positive value**. (A negative returned value indicates an error.) The kvImageGetTempBufferSize flag prevents the function from performing any processing other than to determine the minimum buffer size.
I think the keyword word there is "should be a positive value". 0 is not a positive value.
Reviewed By: javache, yungsters
Differential Revision: D46263204
fbshipit-source-id: baa8fac5b3be6fb5bed02800cd725cc4cf43485a
Summary:
## Summary:
This PR fixes a kernel crash caused by trying to blur greyscale images, as described in this issue:
https://github.com/facebook/react-native/issues/35706#issuecomment-1513359724
## Context:
The CGImageGetBitsPerPixel(imageRef) == 8 expression checks if each pixel of the image is represented by 8 bits.
In an image, each pixel is typically represented by a certain amount of information to store its color. In a grayscale image, for instance, we often use 8 bits per pixel, which allows for 256 different shades of gray (2^8 = 256).
The function vImageBoxConvolve_ARGB8888 works with ARGB images (which stands for Alpha, Red, Green, Blue). If the image is only black & white, it means it's a grayscale image, and hence, it is not compatible with this function, causing the kernel crash.
To prevent the issue, we should also convert grayscale images to ARGB before processing them.
## Changelog:
[IOS] [FIXED] - Fix RCTImageBlurUtils.m Greyscale Crash
Pull Request resolved: https://github.com/facebook/react-native/pull/37508
Test Plan:
```
<ImageBackground
blurRadius={18}
source={{uri: 'https://i.scdn.co/image/ab67616d0000b2737663b2f75fe4d8fb2cac8c27'}}
/>
<ImageBackground
blurRadius={5}
source={{uri: 'https://i.scdn.co/image/ab67616d0000b273d5a219b270d74a266131df18'}}
/>
``
Reviewed By: NickGerleman
Differential Revision: D46071330
Pulled By: javache
fbshipit-source-id: 8c04cbf88d467596c9c8a9de9a380bc10663a0e5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36795
This change bump the min iOS version for React Native to 13.4, to align with company guidelines.
## Changelog:
[iOS][Changed] - Moved the min iOS version to 13.4
Reviewed By: cortinico
Differential Revision: D44634663
fbshipit-source-id: 035e8fcbb395f7394f8253e3ec485ad9937531c2
Summary:
## Changelog:
[Internal] -
While merging a Contributor PR in D43816768, I got curious whether such things as detecting/fixing typos could be automated.
There is a tool called [typos](https://github.com/crate-ci/typos), which, as it turns out, works very well on source code files.
The amount of false positives was minimal, most of the suggestions were valid ones.
And the total amount of typos found and fixed was **more than 300**, which is... quite a bit :)
### Methodology
* Run `typos` separately on `ReactCommon`, `Libraries`, `React`, `ReactAndroid` and `scripts` folders inside `packages/react-native`, e.g.:
```
$ typos -w --config ~/tmp/_typos.toml ~/fbsource/xplat/js/react-native-github/packages/react-native/ReactAndroid
```
Contents of the `_typos.toml` config file:
```
[default.extend-words]
collapsable = "collapsable"
NDK = "NDK"
inout = "inout"
```
(yeah, it really didn't like the "collapsable" word, for some reason ;))
* Inspect all the changes manually and revert false positives (as mentioned, their amount was minimal)
Note that most of the changes are inside things like comments and error messages, however there are a few among identifier name fixes (`typos` is actually quite smart at understanding naming conventions in code) - I kept the suggestions in cases that are local and not part of a public API. There are also misspelled file name changes in a couple of cases.
Reviewed By: NickGerleman
Differential Revision: D44172494
fbshipit-source-id: 86e27edbbb99e09135e3cdd5d7cea8ffeb8307f4
Riccardo Cipolleschi
Kudo Chien
Tim Yung
Rubén Norte
Ruslan Shestopalyuk
Alexander Oprisnik
Pieter De Baets
Phillip Pan
Skander Ellouze
Nick Gerleman
Pieter Vanderwerff
Nick Gerleman
Saad Najmi
Broda Noel
Sam Zhou
zhuwencheng
Lulu Wu
hublot
Jordan Brown
Ramanpreet Nara
Samuel Susla
Oskar Eichler
Luna Wei
Christoph Purrer
Richard Howell
Ruslan Lesiutin