Summary:
In Flow 0.284, we will have a stricter version of `Array<T>.includes`. Instead of accepting `mixed`, we will only accept `T` to help catch logical errors. We did the same for `Array.indexOf` and `Array.lastIndexOf` as well.
This diff pre-suppresses newly discovered errors in part of the codebase.
Changelog: [Internal]
Reviewed By: marcoww6
Differential Revision: D82784398
fbshipit-source-id: 6cb11809844f964e0604d33b9f7a3989074cd1cc
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/53817
What is currently happening, is that the various commits on the release branches like `0.82-stable` are resetting the version of native artifacts to `1000.0.0-<SHA>`.
The reason is that during the `test-all` workflow, we pass the `dry-run` as release type.
That's to prevent the various tools from calling `npm publish` and so on.
The problem is that on the releases branches, the version was already set at branch cut time.
Therefore, we see the version 1000.0.0 reappearing during Android E2E test in the emulator. Similary this is also affecting iOS prebuilds so I'm attempting to fix it here.
Changelog:
[Internal] [Changed] -
Reviewed By: huntie
Differential Revision: D82553599
fbshipit-source-id: 31a52e7df036e700663b3d3dd677973a7a210a30
Summary:
The `--otp` flag is completely unused now, therefore it can be removed.
We don't pass the `NPM_CONFIG_OTP` env variable either as this was done back in the days of CircleCI so I'm cleaning this up.
## Changelog:
[INTERNAL] - Remove unused --otp property from release infrastructure
Pull Request resolved: https://github.com/facebook/react-native/pull/53779
Test Plan: CI
Reviewed By: lunaleaps
Differential Revision: D82453539
Pulled By: cortinico
fbshipit-source-id: 84a6b82a037c754165c21e17976dc534d9a7ba4c
Summary:
bypass-github-export-checks
OSS release infrastructure for the (experimental) React Native DevTools standalone shell.
Currently, binaries are built continuously on Meta infra and served from the Meta CDN using fbcdn.net URLs checked into a DotSlash file in the repo, e.g.:
https://github.com/facebook/react-native/blob/15373218ec572c0e43325845b80a849ad5174cc3/packages/debugger-shell/bin/react-native-devtools#L9-L18
For open source releases we want to primarily distribute the binaries as GitHub release assets, while keeping the Meta CDN URLs as a secondary option. This PR makes the necessary changes to the release workflows to support this:
* `workflows/create-release.yml` (modified): As part of the release commit, rewrite the DotSlash file to include the release asset URLs.
* **NOTE:** After this commit, **the new URLs don't work yet**, because they refer to a release that hasn't been published. Despite this, the DotSlash file remains valid and usable (because DotSlash will happily fall back to the Meta CDN URLs, which are still in the file).
* `workflows/create-draft-release.yml` (modified): After creating a draft release, fetch the binaries from the Meta CDN and reupload them to GitHub as release assets. This is based on the contents of the DotSlash file rewritten by `create-release.yml`.
* `workflows/validate-dotslash-artifacts.yml` (new): After the release is published, all URLs referenced by the DotSlash (both Meta CDN URL and GH release asset URLs) should be valid and refer to the same artifacts. This workflow checks that this is the case.
* If this workflow fails on a published release, the release may need to be burned or a hotfix release may be necessary - as the release will stop working correctly once the Meta CDN stops serving the assets.
* This workflow will also be running continuously on `main`. If it fails on a commit in `main`, there might be a connectivity issue between the GHA runner and the Meta CDN, or there might be an issue on the Meta side.
NOTE: These changes to the release pipeline are generic and reusable; if we later add another DotSlash-based tool whose binaries need to be mirrored as GitHub release assets, we just need to add it to the `FIRST_PARTY_DOTSLASH_FILES` array.
## Changelog:
[Internal] Mirror React Native DevTools binaries in GitHub Releases
Pull Request resolved: https://github.com/facebook/react-native/pull/52930
Test Plan:
### Step 0: Unit tests
I've added unit tests for `dotslash-utils`, `curl-utils`, and for the majority of the logic that makes up the new release scripts (`write-dotslash-release-assets-urls`, `upload-release-assets-for-dotslash`, `validate-dotslash-artifacts`).
### Step 1: Test release commit
Created a test branch and draft PR: https://github.com/facebook/react-native/pull/53147.
Locally created a release commit, simulating the create-release GH workflow:
```
node scripts/releases/create-release-commit.js --reactNativeVersion 0.82.0-20250903-0830 --no-dry-run
```
This updated the DotSlash file in the branch: https://github.com/facebook/react-native/pull/53147/commits/2deeb7e70376ee80b99f27bea4825789f22a89a3#diff-205a9ff6005e30be061eaa64b9cb50b15b0e909dd188e0866189e952655a3483
NOTE: I've also ensured that the `create-release-commit` script correctly updates the DotSlash file when running from a branch that already has a release commit - see screenshot:
<img width="1483" height="587" alt="image" src="https://github.com/user-attachments/assets/1ffd859b-e02b-483d-8067-9cc9116829a4" />
### Step 2: Test draft release
Enabled testing the create-draft-release GH workflow in the test branch using these temporary hacks:
* https://github.com/facebook/react-native/pull/53147/commits/81f334eac5147d4dbf5f6d7d627ddfa52cd197be
* https://github.com/facebook/react-native/pull/53147/commits/6d8851657629de7e0b710ed8f5dd7d0f7b9847cc
* https://github.com/facebook/react-native/pull/53147/commits/1428a8da8b9fb29c45fc33d79f311dd1fe273433
Workflow run: https://github.com/facebook/react-native/actions/runs/17426711373/job/49475327346
Draft release: https://github.com/facebook/react-native/releases/tag/untagged-c6a62a58e5baa37936e1
Draft release screenshot for posterity (since we'll likely delete the draft release after landing this):
<img width="1024" height="814" alt="image" src="https://github.com/user-attachments/assets/1900da15-48f6-4274-b29c-0ac2019d92c0" />
### Step 3: Test post-release validation script
For obvious reasons, I've avoided actually publishing the above draft release. But I have run the `validate-dotslash-artifacts` workflow on the *current* branch to ensure that the logic is correct: https://github.com/motiz88/react-native/actions/runs/17426885205/job/49475888486
Running `node scripts/releases/validate-dotslash-artifacts.js` in the release branch (without publishing the release first) fails, as expected:
<img width="1105" height="748" alt="image" src="https://github.com/user-attachments/assets/ed23a2e2-7a31-42eb-a324-f1d50eafe2fb" />
## Next steps
This PR is all the infra needed ahead of the 0.82 ~~branch cut~~ infra freeze to support the React Native DevTools standalone shell, at least on the GitHub side. ~~Some minor infra work remains on the Meta side, plus some product/logic changes to the React Native DevTools standalone shell that I'm intending to finish in time for 0.82 (for an experimental rollout).~~ EDIT: All the planned work has landed; the feature is code-complete on `main` as well as in `0.82-stable` (apart from this infra change).
As a one-off, once we've actually published 0.82.0-rc.1, we'll want to have a human look at the published artifacts and CI workflow logs to ensure everything is in order. (I'll make sure to communicate this to the 0.82 release crew.) Afterwards, the automation added in this PR should be sufficient.
Reviewed By: huntie
Differential Revision: D81578704
Pulled By: motiz88
fbshipit-source-id: 6a4a48c3713221a89dd5fc88851674c1ddc6bb10
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/53480
Changelog: [Internal]
Improves the way `--version` and the User-Agent header work in `debugger-shell`.
* The same app name and version string format will be used across the `dev` and `prebuilt` flavours. Previously, `dev` would report itself as being `Electron v37.2.6` while `prebuilt` would report `react-native/debugger-shell v0.82.0-main`.
* `prebuilt` now also reports the original Meta-internal commit hash as a suffix `-rFBS..........` added to the semver string taken from `package.json`, while `dev` will have a `-dev` suffix in the same place.
* We do **not** modify the version in `package.json` during the build, nor do we pass the commit hash to `electron/packager`, because this would impose inconvenient platform-specific restrictions on the version string's format.
Reviewed By: huntie
Differential Revision: D81120181
fbshipit-source-id: e730dd35da78dfbb8de326f9a3ab76b747fdb0b3
Summary:
Symbol files wasn't copied correctly when building - as with bundles we did overwrite the files and ended up with only the last symbol file.
This commit fixes this by mapping the framework build folder architecture type to the xcframework slices creating the correct file structure under the Symbols folder.
- Each slice gets a folder with the architecture name under Symbols containing the dSym folder for that slice
- Refactored getting correct architecture folder into a separate function.
- Refactored target folder lookup in copyBundles
- Removed unused async modifier on function
## Changelog:
[IOS] [FIXED] - Fixed how we copy and build the Symbols folder when precompiling ReactNativeDependencies
Pull Request resolved: https://github.com/facebook/react-native/pull/53353
Test Plan: Run nightlies and verify that ReactNativeDependencies.framework.dSym files contains symbol files for all architectures.
Reviewed By: cortinico
Differential Revision: D80692019
Pulled By: cipolleschi
fbshipit-source-id: 77983bc29d1965edf3bc0fcbd9cb3177071991d3
Summary:
When copying bundle files from the platform folders in the .build output, the script had a bug where all bundles were copied - meaning that only the last one would be in the resulting xcframework output.
This caused an issue when we tried to publish an app built with precompiled binaries to AppStore where the field `CFBundleSupportedPlatforms` was wrong and caused the submission to be rejected. This was caused by the script copying the wrong bundle file into the final xcframework outputs.
This issue is described here:
https://github.com/react-native-community/discussions-and-proposals/discussions/923#discussioncomment-14089245
This commit fixes the above error by using the iOS 15 `vtool` to show the actual platform for a given framework and then making sure we don't copy bundles in the wrong way.
Testing this on my local machine for iOS/iOS-simulator/MacOS/catalyst yields the following results (before/after this fix):
**Before:**
```bash
Copying bundles to the framework...
../.build/Build/Products/Debug/ReactNativeDependencies_glog.bundle → ios-arm64
../.build/Build/Products/Debug/ReactNativeDependencies_glog.bundle → ios-arm64_x86_64-maccatalyst
../.build/Build/Products/Debug/ReactNativeDependencies_glog.bundle → ios-arm64_x86_64-simulator
../.build/Build/Products/Debug/ReactNativeDependencies_glog.bundle → macos-arm64_x86_64
../.build/Build/Products/Debug/ReactNativeDependencies_boost.bundle → ios-arm64
../.build/Build/Products/Debug/ReactNativeDependencies_boost.bundle → ios-arm64_x86_64-maccatalyst
../.build/Build/Products/Debug/ReactNativeDependencies_boost.bundle → ios-arm64_x86_64-simulator
../.build/Build/Products/Debug/ReactNativeDependencies_boost.bundle → macos-arm64_x86_64
../.build/Build/Products/Debug/ReactNativeDependencies_folly.bundle → ios-arm64
../.build/Build/Products/Debug/ReactNativeDependencies_folly.bundle → ios-arm64_x86_64-maccatalyst
../.build/Build/Products/Debug/ReactNativeDependencies_folly.bundle → ios-arm64_x86_64-simulator
../.build/Build/Products/Debug/ReactNativeDependencies_folly.bundle → macos-arm64_x86_64
../.build/Build/Products/Debug-iphoneos/ReactNativeDependencies_glog.bundle → ios-arm64
../.build/Build/Products/Debug-iphoneos/ReactNativeDependencies_glog.bundle → ios-arm64_x86_64-maccatalyst
../.build/Build/Products/Debug-iphoneos/ReactNativeDependencies_glog.bundle → ios-arm64_x86_64-simulator
../.build/Build/Products/Debug-iphoneos/ReactNativeDependencies_glog.bundle → macos-arm64_x86_64
../.build/Build/Products/Debug-iphoneos/ReactNativeDependencies_boost.bundle → ios-arm64
../.build/Build/Products/Debug-iphoneos/ReactNativeDependencies_boost.bundle → ios-arm64_x86_64-maccatalyst
../.build/Build/Products/Debug-iphoneos/ReactNativeDependencies_boost.bundle → ios-arm64_x86_64-simulator
../.build/Build/Products/Debug-iphoneos/ReactNativeDependencies_boost.bundle → macos-arm64_x86_64
../.build/Build/Products/Debug-iphoneos/ReactNativeDependencies_folly.bundle → ios-arm64
../.build/Build/Products/Debug-iphoneos/ReactNativeDependencies_folly.bundle → ios-arm64_x86_64-maccatalyst
../.build/Build/Products/Debug-iphoneos/ReactNativeDependencies_folly.bundle → ios-arm64_x86_64-simulator
../.build/Build/Products/Debug-iphoneos/ReactNativeDependencies_folly.bundle → macos-arm64_x86_64
../.build/Build/Products/Debug-iphonesimulator/ReactNativeDependencies_glog.bundle → ios-arm64
../.build/Build/Products/Debug-iphonesimulator/ReactNativeDependencies_glog.bundle → ios-arm64_x86_64-maccatalyst
../.build/Build/Products/Debug-iphonesimulator/ReactNativeDependencies_glog.bundle → ios-arm64_x86_64-simulator
../.build/Build/Products/Debug-iphonesimulator/ReactNativeDependencies_glog.bundle → macos-arm64_x86_64
../.build/Build/Products/Debug-iphonesimulator/ReactNativeDependencies_boost.bundle → ios-arm64
../.build/Build/Products/Debug-iphonesimulator/ReactNativeDependencies_boost.bundle → ios-arm64_x86_64-maccatalyst
../.build/Build/Products/Debug-iphonesimulator/ReactNativeDependencies_boost.bundle → ios-arm64_x86_64-simulator
../.build/Build/Products/Debug-iphonesimulator/ReactNativeDependencies_boost.bundle → macos-arm64_x86_64
../.build/Build/Products/Debug-iphonesimulator/ReactNativeDependencies_folly.bundle → ios-arm64
../.build/Build/Products/Debug-iphonesimulator/ReactNativeDependencies_folly.bundle → ios-arm64_x86_64-maccatalyst
../.build/Build/Products/Debug-iphonesimulator/ReactNativeDependencies_folly.bundle → ios-arm64_x86_64-simulator
../.build/Build/Products/Debug-iphonesimulator/ReactNativeDependencies_folly.bundle → macos-arm64_x86_64
../.build/Build/Products/Debug-maccatalyst/ReactNativeDependencies_glog.bundle → ios-arm64
../.build/Build/Products/Debug-maccatalyst/ReactNativeDependencies_glog.bundle → ios-arm64_x86_64-maccatalyst
../.build/Build/Products/Debug-maccatalyst/ReactNativeDependencies_glog.bundle → ios-arm64_x86_64-simulator
../.build/Build/Products/Debug-maccatalyst/ReactNativeDependencies_glog.bundle → macos-arm64_x86_64
../.build/Build/Products/Debug-maccatalyst/ReactNativeDependencies_boost.bundle → ios-arm64
../.build/Build/Products/Debug-maccatalyst/ReactNativeDependencies_boost.bundle → ios-arm64_x86_64-maccatalyst
../.build/Build/Products/Debug-maccatalyst/ReactNativeDependencies_boost.bundle → ios-arm64_x86_64-simulator
../.build/Build/Products/Debug-maccatalyst/ReactNativeDependencies_boost.bundle → macos-arm64_x86_64
../.build/Build/Products/Debug-maccatalyst/ReactNativeDependencies_folly.bundle → ios-arm64
../.build/Build/Products/Debug-maccatalyst/ReactNativeDependencies_folly.bundle → ios-arm64_x86_64-maccatalyst
../.build/Build/Products/Debug-maccatalyst/ReactNativeDependencies_folly.bundle → ios-arm64_x86_64-simulator
../.build/Build/Products/Debug-maccatalyst/ReactNativeDependencies_folly.bundle → macos-arm64_x86_64
```
**After:**
```bash
Copying bundles to the framework...
../.build/Build/Products/Debug/ReactNativeDependencies_glog.bundle → macos-arm64_x86_64
../.build/Build/Products/Debug/ReactNativeDependencies_boost.bundle → macos-arm64_x86_64
../.build/Build/Products/Debug/ReactNativeDependencies_folly.bundle → macos-arm64_x86_64
../.build/Build/Products/Debug-iphoneos/ReactNativeDependencies_glog.bundle → ios-arm64
../.build/Build/Products/Debug-iphoneos/ReactNativeDependencies_boost.bundle → ios-arm64
../.build/Build/Products/Debug-iphoneos/ReactNativeDependencies_folly.bundle → ios-arm64
../.build/Build/Products/Debug-iphonesimulator/ReactNativeDependencies_glog.bundle → ios-arm64_x86_64-simulator
../.build/Build/Products/Debug-iphonesimulator/ReactNativeDependencies_boost.bundle → ios-arm64_x86_64-simulator
../.build/Build/Products/Debug-iphonesimulator/ReactNativeDependencies_folly.bundle → ios-arm64_x86_64-simulator
../.build/Build/Products/Debug-maccatalyst/ReactNativeDependencies_glog.bundle → ios-arm64_x86_64-maccatalyst
../.build/Build/Products/Debug-maccatalyst/ReactNativeDependencies_boost.bundle → ios-arm64_x86_64-maccatalyst
../.build/Build/Products/Debug-maccatalyst/ReactNativeDependencies_folly.bundle → ios-arm64_x86_64-maccatalyst
```
## Changelog:
[IOS] [FIXED] - Fixed copying bundles correctly to xcframeworks when precompiling ReactNativeDependencies.xcframework
Pull Request resolved: https://github.com/facebook/react-native/pull/53325
Test Plan: Ensure that the info.plist files in the nightlies for the ReactNativeDepdendencies.xcframework has the correct bundles for its targets.
Reviewed By: andrewdacenko
Differential Revision: D80457335
Pulled By: cipolleschi
fbshipit-source-id: aeb4166f66218f72bdd29b6fc579fcc7b6d12844
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/53028
Changelog: [internal]
Now that we have mocking at a more fundamental level (`HighResTimeStamp` API) we can replace other timing mocks with that one.
This does it for `PerformanceEntryReporter` and the `NativePerformance` module.
Reviewed By: hoxyq
Differential Revision: D79557640
fbshipit-source-id: 86579b8bb586190ab7cc8721f30e60b3ef789798
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52777
Changelog: [internal]
This significantly speeds up test execution in Fantom (around 2x in OSS and 6x at Meta) by starting a Metro server before all tests runs and reusing it across all tests to build test bundles, instead of spinning up a new Metro instance every time we run each test.
The architecture change (also considering the previous change in buck prebuilds) looks like this:
{F1980689532}
This is how is impacts execution times (compared to the baseline):
* OSS
* Before: 62s {F1980564286}
* After: 30s (**2x faster**) {F1980564265}
Reviewed By: andrewdacenko
Differential Revision: D78741903
fbshipit-source-id: b209f88925e49cc2a2067e8df9b7fa9a29b4c8d2
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52771
Changelog: [Internal]
It seems we can simply use a std::shared_ptr here
(This was some initial over-engineering which isn't needed as it turns out)
Reviewed By: cipolleschi
Differential Revision: D78771904
fbshipit-source-id: 2925c424d2061ca727636c683ec783ed56e3f0c9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52768
Prettier v3 has an async API. This diff adds in await ahead of the upgrade to prepare for the API change.
Changelog: [Internal]
Reviewed By: pieterv
Differential Revision: D78752354
fbshipit-source-id: c0d27a6c863747b71852e72a22687d1fe1d9f76f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52617
The `test-release-local` script was failing to execute the npx rreact-native run-ios command for some issues with cocoapods.
That command tries to reinstall the pods so there might be some issues when testing.
As an alternative, we can avoid duplicated work by dropping the npx react-native command and, instead, build the app with xcodebuild and install it in the simulator with xcrun.
This is a backport of [this PR](https://github.com/facebook/react-native/pull/52609)
## Changelog:
[Internal] -
Reviewed By: vzaidman
Differential Revision: D78344397
fbshipit-source-id: cf2d9c032966a9be05670259e9532789829349f2
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52618
In 0.81 we dropped the JSC configuration in CI. That means that the artifacts we generate in CI have a slightly different name. The current e2e script failed to run with the ci flag because it was still using the old artifacts name and it was not finding them.
This change adress the problem by:
- using the right artifact names
- removing the --hermes parameter which controlled the Hermes vs JSC scenario.
It is also a port to main of [this PR](https://github.com/facebook/react-native/pull/52606)
## Changelog:
[Internal] -
Reviewed By: cortinico, vzaidman
Differential Revision: D78344244
fbshipit-source-id: a658ba161b867bbad773fe093df9679ea92579b3
Summary:
Bump Metro to 0.83.0.
This release contains some breaking changes for integrators, and a minimum Node.js version of 22.14.
Full release notes: https://github.com/facebook/metro/releases/tag/v0.83.0
Changelog: [General][Changed] Bump Metro to ^0.83.0
Test Plan:
Imported from GitHub, without a `Test Plan:` line.
Rollback Plan:
Differential Revision: D78171925
Pulled By: robhogan
fbshipit-source-id: 7ea5e04d285632a14dd71ba00da872d60f283840
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52543
Prefixing "eager" to the name makes it less confusing. React native already has main queue modules: they're just lazy.
Changelog: [Internal]
Reviewed By: lunaleaps
Differential Revision: D78109287
fbshipit-source-id: 5fa6095d2dd8fcf74fdda64e05483eb487bc8f56
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52564
Currently, `metro-babel-register` has a function as its default export, to which we've tagged on various properties.
This tidies that up to a more idiomatic object of named exports, with `register` as a new one of them.
This also serves to make it more compatible with automatic TypeScript generation.
This is semver breaking, but `metro-babel-register` has very little usage outside Meta projects so isn't expected to be disruptive.
Changelog: [Internal]
Metro changelog:
```
- **[Breaking]**: Move metro-babel-register's main function to a named export `register`
```
Reviewed By: huntie
Differential Revision: D78157559
fbshipit-source-id: c59c9820e9895007345561fed9ccec2273b925c8
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52473
Shared utils that were located in the root of `scripts/` are now colocated closer to their dependencies or moved to `scripts/shared/` — simplifying the root directory layout.
Changelog: [Internal]
Reviewed By: robhogan
Differential Revision: D77873875
fbshipit-source-id: e04dba41a1ef811d32793931033fdfa93afad0cd
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52357
Changelog: [Internal]
Adds a hyper-minimal build script using `electron/packager` that produces custom binaries for the experimental React Native DevTools standalone shell. The main user-facing benefit of this is replacing the Electron name and icon with our own branding.
NOTE: `electron/packager` is designed to include the application code in the resulting binary. This is arguably overkill for us - the current launch model of `electron src/electron/index.js` is actually wholly sufficient for what we need - but I decided to go with the grain of the available tooling for simplicity.
Icon design courtesy of huntie. 🙏
Reviewed By: huntie
Differential Revision: D77591742
fbshipit-source-id: a968465df4f54fba54c874b6300788e151600ed7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52353
This diff aligns breaking change detection script with new snapshot format. It compares hashes to determine if the API changed for each specifier.
Changelog:
[Internal]
Reviewed By: huntie
Differential Revision: D77377762
fbshipit-source-id: e1c69692ace389fb08ae9470b9f9631e53834206
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52352
This diff adds excution of `yarn build-types --validate` to run RN JS API snapshot validation on CI.
### Motivation
Detect react-native public API changes before they land.
Changelog:
[Internal]
Reviewed By: huntie
Differential Revision: D76340729
fbshipit-source-id: 10c465418e0ba4eb05cf557a16119f9756843d9e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52222
Changelog: [Internal]
Introduce environment option to force usage of OSS fantom test runner.
If env is not set - check for BUCK file in tester which is checked in for FB but not for OSS.
Reviewed By: rubennorte
Differential Revision: D77160761
fbshipit-source-id: 1701ff140ff2be1bbeacfb4305e9f89089cacb42
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52300
Targeted improvement to `versionExportedApis` (D77303917) to reduce noise.
This eliminates the false positive from a rename to a local (unexported) type, that does not structurally change the shape of exported types.
Changelog: [Internal]
Reviewed By: rubennorte
Differential Revision: D77314292
fbshipit-source-id: 4de90f5b5f1b622225762b2a73e386538000d54a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52299
Correctness improvement to the `versionExportedApis` transform (D77303917). Now handles namespaced references (e.g. `Animated.Value`) by redirecting to the locally defined type name.
Changelog: [Internal]
Reviewed By: cipolleschi
Differential Revision: D77314293
fbshipit-source-id: 6442d3ab0a3c8bebf6593455b1c2fb74266e657f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52298
Exposes the ability to output inline debug annotations for the `versionExportedApis` transform (D77303917) as a formalised `--debug-version-annotations` CLI flag.
This is helpful for debugging and future maintenance, and will be used to show the effect of the next diffs.
Changelog: [Internal]
Reviewed By: cipolleschi
Differential Revision: D77373723
fbshipit-source-id: 91c91abcb657ab88ee2f8209efccb4024602acc7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52292
Adds a new transform that annotates all exported symbols in our V2 JS API snapshot with a version hash based on the shape of all input types.
This intends to be a reliable mechanism to indicate how changes to local types will ultimately affect exported types.
**Advantages** (over our alternative type inlining prototype)
- More intuitive to developers — in that source type changes are preserved closer to their original source code shapes.
- Enables useful Git blaming of individual exported APIs — hash for each export line will change every time a type is affected, and relevant commits can be looked up based on this.
- Handles recursive types.
- Can be **best-effort** with minimal structural effect over time. We are okay with false positives that over-match input type changes (these are refined later in the stack).
- Similar to this, is **lower risk** in terms of requiring future updates that may pollute the diff of the body of the API snapshot structurally.
**Example change**
Example type change with multiple references: D77378010
{F1979784798}
✅ 8 char hash based on input type shapes printed next to each root-exported identifier
✅ For a source change to the `AccessibilityProps` type, 33 dependent exported types are updated with a new hash
Changelog: [Internal]
Reviewed By: cipolleschi
Differential Revision: D77303917
fbshipit-source-id: 9d43a617697418218eb4951e8e9858d125e222b3
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52280
Changelog: [Internal]
Adds a type-simplifyng transform for the API snapshot, with the goal of resolving some built-in TS types during build time. Most notably, it's able to simplify `Omit` structures emitted by the `flow-api-translator` when translating Flow's type spread operator.
It builds upon a simplified type inlining transform from the previous approach. The type inlining transform is able to handle inlining type references and resolution of built-in TS types on literal types:
- `Omit`
- `Readonly`
- `Partial`
- `keyof`
Reference inlining is performed top-down and built-in type resolution is performed bottom-up, which makes it possible for the second step to assume working on type literals.
Type simplifying transform uses the type inlining to reduce type references encountered inside `Omits` to their literal shapes, which makes possible to determine whether `Omit` is neccessary case-by-case. If `Omit` is redundant, it can be safely removed. If it's not, the omitted keys can be reduced to represent a subset of keys existing in the target type.
It also keeps the ability to resolve `Partial` and `Readonly` types on type literals, simplifying the snapshot further.
An example diff the transform can handle:
Before:
```
export declare type AccessibilityProps = Readonly<
Omit<
AccessibilityPropsAndroid,
| keyof {
accessibilityActions?: ReadonlyArray<AccessibilityActionInfo>
accessibilityHint?: string
accessibilityLabel?: string
accessibilityRole?: AccessibilityRole
accessibilityState?: AccessibilityState
accessibilityValue?: AccessibilityValue
accessible?: boolean
"aria-busy"?: boolean
"aria-checked"?: "mixed" | (boolean | undefined)
"aria-disabled"?: boolean
"aria-expanded"?: boolean
"aria-hidden"?: boolean
"aria-label"?: string
"aria-selected"?: boolean
"aria-valuemax"?: AccessibilityValue["max"]
"aria-valuemin"?: AccessibilityValue["min"]
"aria-valuenow"?: AccessibilityValue["now"]
"aria-valuetext"?: AccessibilityValue["text"]
role?: Role
}
| keyof AccessibilityPropsIOS
> &
Omit<
AccessibilityPropsIOS,
keyof {
accessibilityActions?: ReadonlyArray<AccessibilityActionInfo>
accessibilityHint?: string
accessibilityLabel?: string
accessibilityRole?: AccessibilityRole
accessibilityState?: AccessibilityState
accessibilityValue?: AccessibilityValue
accessible?: boolean
"aria-busy"?: boolean
"aria-checked"?: "mixed" | (boolean | undefined)
"aria-disabled"?: boolean
"aria-expanded"?: boolean
"aria-hidden"?: boolean
"aria-label"?: string
"aria-selected"?: boolean
"aria-valuemax"?: AccessibilityValue["max"]
"aria-valuemin"?: AccessibilityValue["min"]
"aria-valuenow"?: AccessibilityValue["now"]
"aria-valuetext"?: AccessibilityValue["text"]
role?: Role
}
> & {
accessibilityActions?: ReadonlyArray<AccessibilityActionInfo>
accessibilityHint?: string
accessibilityLabel?: string
accessibilityRole?: AccessibilityRole
accessibilityState?: AccessibilityState
accessibilityValue?: AccessibilityValue
accessible?: boolean
"aria-busy"?: boolean
"aria-checked"?: "mixed" | (boolean | undefined)
"aria-disabled"?: boolean
"aria-expanded"?: boolean
"aria-hidden"?: boolean
"aria-label"?: string
"aria-selected"?: boolean
"aria-valuemax"?: AccessibilityValue["max"]
"aria-valuemin"?: AccessibilityValue["min"]
"aria-valuenow"?: AccessibilityValue["now"]
"aria-valuetext"?: AccessibilityValue["text"]
role?: Role
}
>
```
After:
```
export declare type AccessibilityProps = Readonly<
AccessibilityPropsAndroid &
AccessibilityPropsIOS & {
accessibilityActions?: ReadonlyArray<AccessibilityActionInfo>
accessibilityHint?: string
accessibilityLabel?: string
accessibilityRole?: AccessibilityRole
accessibilityState?: AccessibilityState
accessibilityValue?: AccessibilityValue
accessible?: boolean
"aria-busy"?: boolean
"aria-checked"?: "mixed" | (boolean | undefined)
"aria-disabled"?: boolean
"aria-expanded"?: boolean
"aria-hidden"?: boolean
"aria-label"?: string
"aria-selected"?: boolean
"aria-valuemax"?: AccessibilityValue["max"]
"aria-valuemin"?: AccessibilityValue["min"]
"aria-valuenow"?: AccessibilityValue["now"]
"aria-valuetext"?: AccessibilityValue["text"]
role?: Role
}
>
```
Reviewed By: huntie
Differential Revision: D77295302
fbshipit-source-id: 213aef46035bde4f9783353b5344a6986a418399
Sam Zhou
Nicola Corti
Moti Zilberman
Jakub Piasecki
Vitali Zaidman
Christoph Purrer
Moti Zilberman
Christian Falch
Marco Wang
Rubén Norte
Alex Hunt
Riccardo Cipolleschi
Rob Hogan
Ramanpreet Nara
Rob Hogan
Dawid Małecki
Andrew Datsenko