Summary:
X-link: https://github.com/facebook/yoga/pull/1173
In https://github.com/facebook/react-native/issues/35351 we see incorrect child item height when the flex-wrap is enabled, the cross-axis is to be stretched, and main-axis overflow is caused by gap.
In YGDistributeFreeSpaceSecondPass, if we do not have overflow (determined by flexBasisOverflows), we have stretch cross-alignment, and we reason that nothing can add to main axis dimensions, we know we're a single line and want to take full cross dimensions. and can set YGMeasureModeExactly which uses parent dimensions. Guessing an optimization?
If we do have overflow, then we set YGMeasureModeAtMost to find minimum possible cross-axis dimensions instead.
`flexBasisOverflows` incorporates both computed flex basis, and margin, so it is more generally a flag for whether we will wrap. So we should incorporate gap spacing into it. E.g. it is also used for whether we should the match main axis parent dimension of the overall container. This change does just that, and renames the flag to `mainAxisOverflows`.
We will want to cherry-pick the fix for this into RN 0.71 since we have not yet introduced the community to the incorrect behavior, and we expect a lot of usage of flex-gap.
Changelog:
[General][Fixed] - Fix incorrect height when gap causes main axis to overflow and cross-axis is stretched
Reviewed By: yungsters
Differential Revision: D41311424
fbshipit-source-id: bd0c3b5aac478a56878703b6da84fc3993cc14da
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:
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