Summary:
The project.android block is unnecessary and contains a wrong path. Let's use the default path which is `./android`.
## Changelog
[Internal] - Remove project.android block from rn-tester's CLI config
Pull Request resolved: https://github.com/facebook/react-native/pull/35197
Test Plan: Tested locally + will wait for a CI run
Reviewed By: robhogan
Differential Revision: D41013193
Pulled By: cortinico
fbshipit-source-id: 5c76c9b571b23ad71a23a8f3f05a9acb4d6e20b9
Summary:
We accidentally added `-DCMAKE_BUILD_TYPE=Debug` for Hermes which is causing
a really slow engine execution. This fixes it and keep the -DCMAKE_BUILD_TYPE
aligned with the one used on Android.
Changelog:
[iOS] [Fixed] - Correctly set -DCMAKE_BUILD_TYPE for Hermes on iOS
Reviewed By: hramos, cipolleschi
Differential Revision: D40980934
fbshipit-source-id: 30f0455990a911b51eb109bebca8272507302650
Summary:
[Changelog][Internal]
This is to prevent an accidental use of PerformanceObserver while it's still a work in progress.
PerformanceObserver is also moved into a dedicated folder, `Libraries/WebPerformance`.
Reviewed By: rubennorte
Differential Revision: D40978749
fbshipit-source-id: 09645a95bed72902870ebc00c1b4a3d81ab4c829
Summary:
## Changelog:
[Android] [Fixed] - Fix a bug that returns a random number from callback argument `timeRemaining` of `idleCallbacks` registered by `requestIdleCallbacks`.
`global.performance.now()` returns a time from an unknown origin, while `frameTime` is epoch time. Thus, `global.performance.now() - frameTime` is just a random number rather than an elapsed time from the frame start time.
As a simple solution, I would suggest to use `Date.now()`.
Its resolution is lower than `frameTime` due to the security issue in JavaScript VM. So, it loses some precision, but, at least, it is not wrong.
Reviewed By: javache
Differential Revision: D40941461
fbshipit-source-id: b0094e181b97a844d133a9268fe48cd8c8fadfda
Summary:
Support various annotations types in QuickPerformanceLogger markEvent for Android.
Changelog:
[Internal][Changed] - Added support for various markEvent annotation types
Reviewed By: dmitry-voronkevich
Differential Revision: D40852658
fbshipit-source-id: fc4053555f65958653be30a58742c83040a19df1
Summary:
This change moves the default new application template in OSS from Flow to TypeScript. This better aligns with the communities usage, and aligns to the great work that has been happening for TS codegen and built-in types. This used [`react-native-community/react-native-template-typescript`](https://github.com/react-native-community/react-native-template-typescript) as a main reference, maintained by radko93. A few things are different:
1. Updated `types/*` devDependencies to match bumped libraries (e.g. Jest 26 to 20).
2. Removed `types/react-native`
3. Removed explicit `moduleFileExtensions` to Jest config in package.json (TS and TSX and added by default in current versions)
4. Removed overrides to eslint config to disable `no-shadow` and `no-undef`, since this was fixed in the underlying eslint config with https://github.com/facebook/react-native/pull/32644 and https://github.com/facebook/react-native/pull/32655
5. Re-translated `App.js` to be a direct translation (e.g. still a raw function instead of React.FC which is sometimes discouraged)
6. Aligns completely to `tsconfig/react-native` maintained configuration (We no longer have the opinionated override of `skipLibCheck`). The important settings are that `strict` is enabled for, but `allowJS` is also enabled to let users import JS modules without anything unexpected. `esModuleInterop` is enabled, which is needed for consistency with Babel import transformations used by Metro. Consistent with our [current documentation](https://reactnative.dev/docs/typescript) built against the community template, `tsc` will typecheck your code without emitting(building) anything.
[Documentation](https://reactnative.dev/docs/typescript) will need to be updated as a followup.
Changelog:
[General][Changed] - Use TypeScript by default for new applications
Pull Request resolved: https://github.com/facebook/react-native/pull/35165
Test Plan: Added usage of `tsc` and `jest` when validating a newly built app. Passes in CircleCI `test_js` job. This also meant removing some cases of copying packages into the users app to pull in the root Metro config (we seem to be able to use the template Metro config consistent with what real apps would get).
Reviewed By: cortinico
Differential Revision: D40911951
Pulled By: NickGerleman
fbshipit-source-id: 15994534235695e91cf994ad06ba2183dfc89a50
Summary:
In the top js errors there are 2 mids related to segment fetching:
- requireForFacebook.js:unknownModuleError (https://www.internalfb.com/logview/details/facebook_android_javascripterrors/ba11461526aff8a6842401b35b02f5a4), 11.64 K vs. 524
- asyncRequire.js:verifySegment (https://www.internalfb.com/logview/details/facebook_android_javascripterrors/5452ba893b8d9ba8e97e070cf6976b65) 5.39 K vs. 180
Both errors will result in surface not loading.
A lot of traces have logs similar with the following:
```11-01 19:57:51.166 27735 7626 W fb4a.BridgelessReact: registerSegment(segmentId = "1090", path = "/data/data/com.facebook.katana/app_overtheair/resources/412137089/414433453/hbc-seg-1090__DELIM__main.jsbundle")
11-01 19:57:51.167 27735 7445 I ReactNativeJS: Module 39122 in segment 0 doesn not exist moduleDefiner
11-01 19:57:51.171 27735 7445 E ReactNativeJS: Error: Requiring unknown module "39122"., js build: 414433453
11-01 19:57:51.175 27735 7445 E ReactNativeJS: Error: Segment meta module is not setup properly. Details: segmentId = 1090, metaModule === undefined
11-01 19:57:51.175 27735 7445 E ReactNativeJS:
11-01 19:57:51.175 27735 7445 E ReactNativeJS: This error is located at:
```
RegisterSegment lives through 3 threads while in bridge there are only 2 threads involved (native & JS):
- Native thread, log printed (fb4a.BridgelessReact: registerSegment...)
- Background thread: no log, added in this diff (Finish registerSegment...)
- JS thread: logs not printed, should print logs here:
https://www.internalfb.com/code/fbsource/[60521987354ed1ef9a0d10bafc60db3c25302ab4]/xplat/ReactNative/venice/ReactInstance.cpp?lines=308-330
Since the JS thread logs aren't printed and there are segment errors right after calling registerSegemnt, I think registerSegment is not done. It could be caused by:
- ReactInstance being null, I added logs in background thread to verify (Finish registerSegment...) since dispatching to background thread relies on non-nullable ReactInstance.
- Work on JS thread hasn't been executed when trying to use/verify the segment. I added atomic method ```registerSegmentAtomic``` to make sure JS thread is blocked until segment is fully registered.
```registerSegmentAtomic``` will be tested behind gating added in D40917444.
Changelog:
[Android][Changed] - Add feature flag enableAtomicRegisterSegment
Reviewed By: RSNara
Differential Revision: D40921759
fbshipit-source-id: 84221aa81f0c549f931a4847b154187299639ef4
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35166
The Hermes source code is not included in the RN npm package. This piece of code is a remnant from an early experimentation into integrating Hermes more tightly with React Native. We ended up using a combination of the scripts in `scripts/hermes` to fetch the source code from GitHub and relying on prebuilts for stable releases.
Added `strict()` flag to ensure the script fails immediately if an unrecognized flag is passed.
Avoid logging temp publishing folder value to console when `--help` is used.
Changelog: [internal]
Reviewed By: cortinico
Differential Revision: D40918939
fbshipit-source-id: 2e62ab16467c4c67f03efdf5211a156cb70e0b11
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35123
**Context**
On RN Desktop, images can be copy/pasted into text inputs.
When copy/pasting local files w/ semi-colons in the filename (`/downloads/devices:pre-call-IMG_346C38284B2B-1.jpeg`), RN would throw this error.
{F785684529}
The error was due to no having the correct asset loader due to the local file path being parsed incorrectly.
To parse the url, we convert the string URI to a `NSURL` using a custom convertor fn.
The conversion was matching any `:` and assuming it was a network url scheme:
https://www.internalfb.com/code/archon_react_native_macos/[fde4113acd89fb13ee11636c48b59eac49c21bae]/React/Base/RCTConvert.m?lines=97-111
When an image path with `:` in the name was passed to this, it was assuming it was a valid network url and not file path.
Because this is a local filepath, the image path needs to be a filesystem url. Since this was parsed as network url, it did not have the `file://` prefix and would not pass this check, causing the loader to throw.l
https://www.internalfb.com/code/fbsource/%5B60d9d5e67383%5D/xplat/js/react-native-github/Libraries/Image/RCTImageLoader.mm?lines=220-230
## Changelog
[iOS] [Added] - Add support for parsing files w/ `:` in filename
Reviewed By: christophpurrer, philIip
Differential Revision: D40729963
fbshipit-source-id: 2f3adcabc8f0f1f22cbfca69c3484e72b1d93d25
Summary:
Just bumping RNGP to make the new sources avialable to the template.
Changelog:
[Internal] [Changed] - Bump RNGP to 0.71.8
Reviewed By: robhogan
Differential Revision: D40948246
fbshipit-source-id: c6a193fcdc0675be9ef7f1320d63e884b8b65daa
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35181
As the title says, this unblocks `test_buck` by removign the lambdas used inside test.
Changelog:
[Internal] [Changed] - Fix test_buck by not using lambdas inside ReactImagePropertyTest
Reviewed By: cipolleschi
Differential Revision: D40958412
fbshipit-source-id: 60b8609a25985230dfd6c4dcdf983dc2a8cfaf64
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35169
This reorganizes typing structure a bit.
`Utilities.d.ts` was originally added for utilitiy types but I ended up leaving it a grab bag of types that didn't belong to any individual bit of code. Out of what is in it right now, `Insets` was actually public, and seems to have been imported.
We also run into files around the renderer which are [currently overwritten](https://github.com/facebook/react-native/commits/e286da25fc83324363486eb668806aca179f74b3/Libraries/Renderer/implementations/ReactNativeRenderer.d.ts) by the React sync script.
Finally, all of the top-level imports of `Utilities` were auto-generated by VS Code, but fail in real apps. I think this is because our tsconfig sets a `baseUrl` to allow resolution from the types folder, so the tooling in the RN repo will use that, but it breaks in real apps that don't have that mapping.
This splits all these up into a couple separate directories that are hopefully easier to reason about, and removes `Omit` which has been a builtin type for quite some time (we were actually already using built-in `Omit`).
Changelog:
[General][Fixed] - Fixup TS Organization
Reviewed By: cipolleschi
Differential Revision: D40932319
fbshipit-source-id: 0b6e3e3eda603885b4dc01dcb9f5233aa546d128
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35178
I forgot to add the logic to fetch the -SNAPSHOT version when on nightlies.
This code takes care of it.
Changelog:
[Internal] [Changed] - Make sure nightly versions are using the -SNAPSHOT artifacts
Reviewed By: cipolleschi
Differential Revision: D40939367
fbshipit-source-id: 29d60cf281d30b3dbd05d7ea1c766541a8fab90a
Summary:
Saw in the logs an ever increasing number of warnings coming from WebSocketModule about requesting an instance that has already gone away.
On module invalidation we should close all outstanding websockets, as they will no longer be able to send events to JS.
Changelog: [Android][Fixed] On instance destroy, websockets are correctly closed
Reviewed By: mdvacca
Differential Revision: D40897255
fbshipit-source-id: 1578de8baa342479d14ee1070c3314d45c7fbd8d
Summary:
This PR is a follow up of https://github.com/facebook/react-native/pull/35075 and https://github.com/facebook/react-native/commit/1546666a6d713ef756b2f11de9581e3b2bbe08dc to ensure that even in the local e2e testing scenario the new maven approach is followed - without this, RNTestProject on Android won't work, like so:
<img width="1905" alt="Screenshot 2022-10-27 at 12 15 38" src="https://user-images.githubusercontent.com/16104054/198334105-30fb2037-4e7c-4814-8c3f-2412ba0bd49f.png">
And iOS will always build everything from source every time.
This PR addresses both by generating the artifacts locally, and passing them to RNTestProject as if they were coming from a url (mimicking as closely as possible the behaviour for the final user)
In doing so, there's been some refactoring to prep the ground for follow up work.
* refactor CI to rely less on scripts directly in the CircleCI config, but invoke .js ones
* we should be able to trigger more the "manual" artifacts generation so that it will only happen once between RNTester and RNTestProject, and we can pass existing artifacts to the other flows.
* once all of this in place, a very good improvement would be to be able to download the maven artifacts kind of like nightlies and stables do. This will only be viable by checking that there's no local changes, after which there needs to be logic to pull down from CircleCI the artifacts based on git commit <-> circleCI job references.
---
While at it, I've also fixed the hermes-engine podspec logic for detecting if it's on CI: basically the local e2e script needs to align with the changes done here: https://github.com/facebook/react-native/commit/4b512077354eb4702ce144e9958d7513c1607275
but as you can see there, the condition was actually inconsistent across the various files, so realigned to `CI === 'true'`. We probably didn't catch that so far 'cause the other condition in the hermes podspect (existence of `hermestag_file`) is only true on release branches and this new logic has not been in any release branches yet.
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[Internal] [Fixed] - add logic to local e2e script to handle maven local for iOS and Android accordingly
Pull Request resolved: https://github.com/facebook/react-native/pull/35104
Test Plan:
Run ` yarn test-e2e-local -t RNTestProject -p Android` successfully.
Run ` yarn test-e2e-local -t RNTestProject -p iOS` successfully. On the pod install stage, you will see `[Hermes] Using pre-built Hermes binaries from local path.`
Reviewed By: dmytrorykun
Differential Revision: D40893239
Pulled By: cipolleschi
fbshipit-source-id: a31217ec4f177383c62292d00fabc4cbe4391cfd
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35176
This commit extends the ReactNative-application.cmake logic so
that if the app is using codegen at the app level, the generate library
is properly built and linked.
It helps us simplify the RN Tester setup and makes it easier for app users
to use the codegen at the app level.
Changelog:
[Internal] [Changed] - [Android] Link against the app codegen if available
Reviewed By: cipolleschi
Differential Revision: D40936941
fbshipit-source-id: 26fa4d764fb369c987e94e0c3bce61841b982b27
Summary:
The documentation for `useColorScheme()` suggested that the user's preferred color scheme will be 'Dark Mode'. Instead suggesting 'Dark Mode' as an example of what the user's preferred color scheme could be is more correct.
## Changelog
[INTERNAL] [FIXED] - Edited documentation for `useColorScheme()` hook
Edited
```javascript
/**
* A new useColorScheme hook is provided as the preferred way of accessing
* the user's preferred color scheme (aka Dark Mode).
*/
export function useColorScheme(): ColorSchemeName;
```
to
```javascript
/**
* A new useColorScheme hook is provided as the preferred way of accessing
* the user's preferred color scheme (e.g. Dark Mode).
*/
export function useColorScheme(): ColorSchemeName;
```
Pull Request resolved: https://github.com/facebook/react-native/pull/35141
Test Plan: Documentation only - no testing required.
Reviewed By: cipolleschi
Differential Revision: D40934781
Pulled By: rshest
fbshipit-source-id: acac8947c3f99016839be27f505066e8992a20fa
Summary:
Improving test coverage in anticipation of some changes being made to `hermes-utils.js`.
Moved test scripts to `hermes/__tests__` and grouped related tests.
We have been delegating some of the work to local binaries via `execSync`, which can be hard to mock or test. We now use a proxy `delegateSync` method that uses `spawnSync` internally to break down the invocation into `command`, `arguments`, `options`. Instead of simply mocking based on the command being executed, we can now conditionally mock based on the arguments being passed.
Added a `createTarballFromDirectory` method. This can be used later when creating different tarballs.
Added `populateMockFilesystemWithHermesBuildArtifacts()` to mock the filesystem state after Hermes has been built.
Changelog: [internal]
Reviewed By: cipolleschi
Differential Revision: D40871802
fbshipit-source-id: 4348d3c38926ec7eb13d794040a9040010879f58
Summary:
Include dSYMs when building the universal XCFramework for Hermes iOS.
CocoaPods should pick up dSYMs automatically when using `vendored_framework` if:
- `hermes.framework` has a `hermes.framework.dSYM` in the same base directory
- `hermes.xcframework` has a `dSYMs` folder with a `hermes.framework.dSYM` in it, for each slice
The dSYMs for the macOS hermes.framework are already being created.
Changelog: [Internal]
Reviewed By: cipolleschi
Differential Revision: D40790250
fbshipit-source-id: 50fcb3492434637b00458c1aa443ac6ec5472fac
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35162
The dSYMs for Apple will not be distributed as part of the prebuilts tarball. They can still be included in the tarball by passing a `-d` flag to the create-tarball script.
Changelog: [internal]
Reviewed By: cipolleschi
Differential Revision: D40813679
fbshipit-source-id: 26dee8251684c5ecad649ccd27ce688cfe88ec8f
Summary:
Changelog: [Internal]
Override logic for determining whether a dispatched `Event` triggers a native `EventAnimationDriver`.
Natively driven AnimatedEvents on bubbling events is not supported. `PointerEvents` requires this and this diff adds custom matching logic such that if a parent specifies an `AnimatedEvent` on `onPointerMove` and a child view dispatches it, the `AnimatedEvent` will still fire.
Reviewed By: javache
Differential Revision: D38722563
fbshipit-source-id: 7cde57eaff9584b33c6ab15f1fe85c0a9bac132e
Summary:
Changelog: [Internal] - Refactor match logic on determining whether to run an EventAnimationDriver (drivers for natively animated events) for an Event dispatched.
Previously, drivers were stored by key on the NativeAnimatedNodesManager (based on event handler and viewTag) and has been refactored to be stored in a list for easier matching.
This diff changes it so the match logic for running an EventAnimationDriver happens on the Event instance. This change is motivated by PointerEvents needing custom match logic (done on a following change).
Reviewed By: javache
Differential Revision: D40691002
fbshipit-source-id: e4f6742a2af3b751214aefa1fc069f65e8e71d77
Summary:
As part of unifying JS QPL interface, I'm bringing markerAnnotate to the parity with Web version.
At the moment it supports only string annotations, but I'm adding support for ints, arrays of ints, arrays of strings, etc.
## Changelog:
[Internal] [Changed] - Refactored markerAnnotateWithMap -> markerAnnotate
Reviewed By: eddyerburgh
Differential Revision: D40796535
fbshipit-source-id: 9831e353036835b97bb7b2f60085016034c04269
Summary:
## Changelog:
[Internal] [Added] - Adding new markerAnnotateWithMap to the QPL.
This is part of bigger effort to unify JS QPL interfaces across platforms.
Reviewed By: eddyerburgh
Differential Revision: D40796537
fbshipit-source-id: a75b97c20ca411653552228f7dc2fcbedd8ddca9
Summary:
This is a follow up action item from S295231 and T136039462 where we want to make sure null uri in image source is handled properly. This diff adds an unit test to make sure we are using transparent image when uri is null.
Changelog:
[Android][Internal] - Add unit test to ImageView for null uri in source
Reviewed By: javache
Differential Revision: D40732791
fbshipit-source-id: fd468bfe7c33a4f3f8913ead3e84a1770d7c907f
Summary:
## Context
If React Native is built from *main* of any non-stable commit, then Hermes is built from source. The build is performed by `build-ios-framework.sh` and `build-mac-framework.sh` scripts in `hermes-engine.podspec` `prepare_command` stage. Since those scripts have no access build target information, they build all possible architectures and platforms just in case. That takes ages.
## Solution
The idea is to integrate build script into Xcode *run script* phase, and use build target information to build Hermes for active architecture only.
## Implementation
- Existing behaviour remains unchanged for local tarball and remote prebuild cases.
- `build-hermesc-xcode.sh` builds Hermesc as `hermes-engine.podspec` `prepare_command`. Default build location is `react-native/sdks/hermes-engine/build_host_hermesc`.
- `build-hermes-xcode.sh` builds Hermes in 'Build Hermes' Xcode script phase. It uses `$PLATFORM_NAME`, `$CONFIGURATION`, `$ARCHS`, `$IPHONEOS_DEPLOYMENT_TARGET` and `$MACOSX_DEPLOYMENT_TARGET` environment variables to configure cmake project so it builds only active architecture. The script also gets RN version, *cmake* path and *hermesc* path from the podspec.
- `copy-hermes-xcode.sh` copies Hermes.framework inside the app bundle. This script phase is added to the user app target in a `post_install` hook, after pods are integrated in a user project.
- `OTHER_LDFLAGS -framework "hermes"` added to the user project to enable linking against Hermes.framework.
- If `HERMES_OVERRIDE_HERMESC_PATH` is set, then Hermesc building is skipped, and `HERMES_OVERRIDE_HERMESC_PATH` is used for `build-hermes-xcode.sh`.
- `HERMES_CLI_PATH` is injected into user project config to enable Hermes source maps in `react-native-xcode.sh`.
## Things that didn't work
- *Running build-hermesc-xcode.sh in Xcode run script phase*. This doesn't work because Hermesc is supposed to be built for macos, and if build target is ios, then Xcode configures environment in such a way that Hermesc build fails.
- *Installing Hermesc into CocoaPods download folder*. So it then ends up in `Pods/hermes-engine/build_host_hermesc`, and all the housekeeping is handled by CocoaPods. This doesn't work because cmake uses absolute paths in a configured project. If configured project is moved to a different location, nothing builds.
- *Installing Hermesc directly into Pods/hermes-engine*. This doesn't work because CocoaPods runs prepare_command before Pods folder clean up, and everything gets wiped.
## Known issue
- If `Pods/hermes-engine` is manually removed, then `sdks/hermes-engine/build_host_hermesc` must also be removed before running `pod install`. Otherwise cmake will complain about stale cache:
```
CMake Error: The source "<CocoaPodsCache>/hermes-engine/<hash2>/CMakeLists.txt" does not match the source
"<CocoaPodsCache>/hermes-engine/<has1>/CMakeLists.txt" used to generate cache. Re-run cmake with a different source directory.
```
## Benchmark
MacBook M1 2021 32 GB.
```
export REACT_NATIVE_PATH=~/fbsource/xplat/js/react-native-github
cd $REACT_NATIVE_PATH/packages/rn-tester
pod install
rm -rf $REACT_NATIVE_PATH/sdks/hermes-engine/build_host_hermesc
cd $REACT_NATIVE_PATH/packages/rn-tester/Pods/hermes-engine
echo 't1=$(date +%s); $@; t2=$(date +%s); diff=$(echo "$t2 - $t1" | bc); echo Operation took $diff seconds.' > /tmp/benchmark.sh
```
```
# Before
export BUILD_TYPE=Debug
export JSI_PATH=$REACT_NATIVE_PATH/ReactCommon/jsi
export RELEASE_VERSION=1000.0
export IOS_DEPLOYMENT_TARGET=iphonesimulator
export MAC_DEPLOYMENT_TARGET=12.6
cd $REACT_NATIVE_PATH/packages/rn-tester/Pods/hermes-engine
. /tmp/benchmark.sh $REACT_NATIVE_PATH/sdks/hermes-engine/utils/build-ios-framework.sh
# Operation took 252 seconds
. /tmp/benchmark.sh $REACT_NATIVE_PATH/sdks/hermes-engine/utils/build-mac-framework.sh
# Operation took 179 seconds
```
```
# After
. /tmp/benchmark.sh source $REACT_NATIVE_PATH/sdks/hermes-engine/utils/build-hermesc-xcode.sh $REACT_NATIVE_PATH/sdks/hermes-engine/build_host_hermesc
# Operation took 59 seconds.
. /tmp/benchmark.sh xcodebuild -workspace $REACT_NATIVE_PATH/packages/rn-tester/RNTesterPods.xcworkspace -scheme hermes-engine
# Operation took 106 seconds.
```
|Before|||After|||
|--|
|iOS framework (s)|Mac framework (s)|Total (s)|Hermesc (s)|Target-specific framework (s)|Total (s)|
|252|179|431|59|106|**165 (-266) (-61%)**|
The performance win is fixed, and does not depend on the project size and structure.
As an example, this is how these changes affect build time of RNTester.
|Before||||After|||
|--|
||Pod install (s)|Xcode build (s)|Total (s)|Pod install (s)|Xcode build (s)|Total (s)|
|Clean build|1219|132|1352|734 (-485)|249(+117)|**983 (-369)**|
|Incremental build|82|30|112|105 (+23)|**34 (+4)**|139 (+27)|
The most important values here are the total clean build time and the incremental Xcode build time. The first one went down by 369 seconds, the second one went up by 4 seconds. I consider it a reasonable tradeoff.
The extra 4 seconds in the incremental Xcode build time can potentially be mitigated by setting up output file lists for the new script phases.
allow-large-files
Changelog:
[iOS][Changed] - Hermes is integrated into Xcode build.
Reviewed By: hramos
Differential Revision: D40063686
fbshipit-source-id: e6993d62225789377db769244bc07786cc978a27
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35160
With the simplified migration to the new arch, we are offering a function in cocoapods that takes care of configuring all the dependencies for libraries.
That function was not setting the proper version of C++ for the library. This could lead to build problems.
This Diff make sure that the libraries that are created with this function call have the proper C++ version.
NOTE: we already have a post install hook that was setting the the proper C++ version, but that was only working for the project. Plus, we can't read that version from the React-Core podspec because at the podspec definition time, cocoapods has not read that yet. Therefore, I just hardcoded the C++ version on top of the file, so it will be easier to update if we decide to change it.
## Changelog
[iOS][Fixed] - Make sure that libraries created with `install_modules_dependencies` has the right C++ version.
Reviewed By: dmytrorykun
Differential Revision: D40894561
fbshipit-source-id: a5187be2d85888a335d4c033f16fdacaf2c945f9
Summary:
This pull request migrates the dimensions example to using React Hooks.
## Changelog
[General] [Changed] - RNTester: Migrate Dimensions to hooks
Pull Request resolved: https://github.com/facebook/react-native/pull/35084
Test Plan: The animation works exactly as it did as when it was a class component
Reviewed By: yungsters
Differential Revision: D40779014
Pulled By: NickGerleman
fbshipit-source-id: e740684d3022a945da5abc33b2e8834c6cfabb97
Summary:
`exact_empty_objects` is on by default in 0.191, delete usage
Changelog: [Internal]
Reviewed By: SamChou19815
Differential Revision: D40822684
fbshipit-source-id: 8e84f0542e6b66049cac34e429f0b724f85a9557
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35156
There are two tarballs: the source code for Hermes that is downloaded from GitHub, and the hermes-runtime-darwin-{}-v{}.tar.gz tarball with prebuilt artifacts that is built in CI.
Renamed some methods to make it clearer which tarball they work with.
Changelog: [internal]
Reviewed By: cipolleschi, dmytrorykun
Differential Revision: D40812290
fbshipit-source-id: a2c865e1d1461829fe8d468f52deeb55f3565cb0
