Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42626
Right now this is done by some combination of string splitting, JS side regexing, etc. This will not scale for math expressions, and gets more and more annoying when we try to add more.
In preparation for adding more units, this adds a tokenizer/lexer for a subset of CSS grammar, based on the spec. This is not hooked up to anything yet, and doesn't add a parser.
The algorithm uses a subset of the comprehensive instructions provided at https://www.w3.org/TR/css-syntax-3/#tokenizer-algorithms as a reference, with some major simplifications.
Changelog: [Internal]
Reviewed By: joevilches
Differential Revision: D53030661
fbshipit-source-id: c48bc572c5e02daee0b05e91830f2441528193d1
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42651
Lots of boilerplate to define hash functions for different enums, so we can use them in `hash_combine`. This should not be needed, and seems like it might have been an artifact of older C++ version of standard library with bugs.
https://en.cppreference.com/w/cpp/utility/hash
> In addition to the above, the standard library provides specializations for all (scoped and unscoped) enumeration types. These may be (but are not required to be) implemented as std::hash<std::underlying_type<Enum>::type>.
Also moves `hash_combine` SFINAE to concepts for clarity and better error messages.
Changelog: [Internal]
Reviewed By: christophpurrer
Differential Revision: D53074535
fbshipit-source-id: 5fcb653dbe4aa51aa3d9d96f1511da3b7541270d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42694
D53115471 commited all the automatically fixable lints by `ANDROIDLINT`. When I looked again, closer, there was one automatic fix that I'm fairly sure is incorrect.
Before:
`outTransform.postTranslate((int) (dx + 0.5f), (int) (dy + 0.5f));`
After:
`outTransform.postTranslate((dx + 0.5f), (dy + 0.5f));`
I think the linter did this because the underlying API accepts a float, so this was (incorrectly) seen as an extraneous cast causing precision loss, but the previous behavior was using the cast and addition to round the float, instead of adding 0.5 to it.
This replaces the call with an explicit rounding, for the same behavior as before (though, I'm not sure if the rounding is intentional, since in and out are both fp).
Changelog: [Internal]
Reviewed By: joevilches
Differential Revision: D53158801
fbshipit-source-id: d268a5c429663dd7da0bfce2d717589986601196
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42616
PropsParserContext is an entity in Core with a lot of baggage. We used it in graphics only to access the `surfaceId` and the `contextContainer`. We don't need to bring to graphics the whole dependencies of core due to these two parts.
This change break the dependency by passing along only the elements that we actually need.
## Changelog
[Internal] - break dependencies between graphics and core by removing the include of the PropsParserContext
Reviewed By: sammy-SC
Differential Revision: D52999204
fbshipit-source-id: a4b92fc11238f5caa63e39a6e286273ab671c8de
Summary:
fixed homepage url in package.json file of community cli plugin.
## Changelog:
[GENERAL][CHANGED] - changed community cli plugin homepage url.
<!-- 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
Pull Request resolved: https://github.com/facebook/react-native/pull/42696
Test Plan: community-cli-plugin homepage url must be opened correctly.
Reviewed By: rubennorte
Differential Revision: D53179709
Pulled By: huntie
fbshipit-source-id: 7949a897d4fe1da228fce323fa8bb32640194273
Summary:
Just small fix for those who are copy & pasting commands from error message.
## Changelog:
[INTERNAL] [CHANGED] - Update erorr message to use `npx` when calling `react-native`
Pull Request resolved: https://github.com/facebook/react-native/pull/42691
Test Plan: _
Reviewed By: cipolleschi
Differential Revision: D53177186
Pulled By: cortinico
fbshipit-source-id: e680cde81fde1f560dfeb1a85c8ad90090d69653
Summary:
Cocoapods 1.15 (https://github.com/facebook/react-native/issues/42698) current breaks the build, limit to version >= 1.13 & < 1.15
This is currently broken and affecting users, we'll remove this limit once Cocopods fixes the regression. It's currently blocking 0.73.3.
## Changelog:
[iOS][Fixed] don't allow cocoapods 1.15.
<!-- 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
Pull Request resolved: https://github.com/facebook/react-native/pull/42702
Test Plan:
```
bundle exec pod install
```
Reviewed By: cipolleschi
Differential Revision: D53180111
Pulled By: blakef
fbshipit-source-id: 4c5dd11db6d208e8d71249443a8f85e601913abd
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42675
`ANDROIDLINT` config now has a base setup for RN. This enables it in arc linter, and fixes automatically fixable issues.
Changelog: [Internal]
Reviewed By: joevilches
Differential Revision: D53115471
fbshipit-source-id: 2556c21770f7c7ca54d1bccfff527d39df20101e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42686
D53072714 accidentally removed this call, which sets the values for props which have duplicates, and some precedence between them.
This organization is janky, and will be removed in D53073913 where we decuple the props from Yoga style (so the precedence and parsing order becomes a lot more sane).
Changelog:
[Android][Fixed] - Restore missing call to `convertRawPropAliases`
Reviewed By: mdvacca
Differential Revision: D53144603
fbshipit-source-id: 85da722b23992ea75fb681f1db15e62a0daa2a51
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42685
This diff fixes the TextInput-textStyles-e2e test.
The rootcause of this issue is that we were updating the lineHeight of ReactEditText (AppCompatEditText) when lineHeight is set as a prop from React.
This is a problem, because one one side lineHeight is managed by React Native (setting styles in the spannables) and on the other side we ar calling setLineHeight on AppCompatEditText, which breaks the rendering.
We should only manage lineHeight using RN styles, that's why I'm removing call to super.setLineHeight()
Changelog: [internal] internal
Reviewed By: NickGerleman
Differential Revision: D53142429
fbshipit-source-id: cedf803171a490afa67252e9e7f83749502326e6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42628
Changelog: [iOS][Deprecated] Retrieving initial notification requires UNUserNotificationCenterDelegate setup instead of reading UIApplicationLaunchOptionsLocalNotificationKey
# how to migrate:
if you are currently using `getInitialNotification` to check the notification on an app start (warm or cold), you will need to do a migration.
have an object become the delegate of `UNUserNotificationCenterDelegate`. you can use your app's `AppDelegate` to do this.
then, override `userNotificationCenter:didReceiveNotificationResponse:withCompletionHandler:`. in the implementation, add these lines:
if ([response.actionIdentifier isEqualToString:UNNotificationDefaultActionIdentifier]) {
id module = _reactHost ? [[_reactHost getModuleRegistry] moduleForName:"PushNotificationManager"]
: [_bridge moduleForClass:[RCTPushNotificationManager class]];
if ([module isKindOfClass:[RCTPushNotificationManager class]]) {
RCTPushNotificationManager *pushNotificationManager = (RCTPushNotificationManager *)module;
pushNotificationManager.initialLocalNotification = response.notification;
}
}
# reasoning:
when you start an app from a push notification, the `UIApplicationLaunchOptionsLocalNotificationKey` in `application:didFinishLaunchingWithOptions:` will contain the notification metadata that started the app. additionally, this was stored on the bridge, which is not compatible with the new architecture. however, `UIApplicationLaunchOptionsLocalNotificationKey` has been deprecated since iOS 10, which this PR aims to address.
apple's supported API to do this is `userNotificationCenter:didReceiveNotificationResponse:withCompletionHandler:` which is on `UNUserNotificationCenterDelegate`. this is a significant change from a pull to push model. in order to make this change without having to rearchitect the product layer, we're going to store the notification on the notification native module.
another caveat is that the API follows the delegation pattern, not the listener pattern. that means we can't make our notificaiton native module the delegate here - the app will probably need `UNUserNotificationCenterDelegate` to be a top level object - usually the scope of the app delegate.
in future, i actually think we need to unify this with `handleLocalNotificationReceived:`, but right now there's forked handling between platforms and some product code is only using the pull model, so this is still the minimum change in the product layer.
Reviewed By: ingridwang
Differential Revision: D52897071
fbshipit-source-id: 579578d1b3128c5f7e81249c75cf7655b8e360e2
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42684
This addressed threading issue like this:
```
Attempting to set an overrideUserInterfaceStyle from a background thread. Modifying a view controller from a background thread is not supported
```
Changelog: [iOS][Fixed] Fixed potential threading issues accessing UIKit from background in RCTAlertManager
Reviewed By: philIip
Differential Revision: D52999194
fbshipit-source-id: 8ce8a89ef932ca9b75cb93d3c9f102a6b0494580
Summary:
Move all `ReactSpan` subclasses to a separate folder.
This is a minor improvement in the context of my multi-PR work on https://github.com/react-native-community/discussions-and-proposals/issues/695.
I'm adding a new span class later, which was the direct motivation for this change.
## 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
-->
[INTERNAL] [CHANGE] - Move all `ReactSpan` subclasses to a separate folder
Pull Request resolved: https://github.com/facebook/react-native/pull/42594
Reviewed By: mdvacca
Differential Revision: D53123733
Pulled By: cortinico
fbshipit-source-id: 10db214a520d157c231e6f3b97948b4209a7ad4b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42678
Changelog: [internal]
This is a re-application of https://github.com/facebook/react-native/pull/42430, which had to be reverted because of crashes in optimized builds on Android:
```
Abort Reason: terminating due to uncaught exception of type facebook::jni::JniException: java.lang.ClassNotFoundException: com.facebook.react.internal.featureflags.ReactNativeFeatureFlagsProvider
```
The root cause of that was that that class was removed because it wasn't statically referenced from Kotlin/Java, but it was dynamically referenced from C++ (in `ReactNativeFeatureFlagsProviderHolder.cpp`).
This applies the same changes + adds `DoNotStrip` annotations for the affected class and all its methods.
Reviewed By: huntie
Differential Revision: D53122992
fbshipit-source-id: efc4d5636a3f2d39b86e9c098bff408b6688b80b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42656
I'm bumping the NDK to 26.1. As we already have a bump lined up to 26.0 on main,
it makes sense to go to .1 as it's declared the LTS:
https://github.com/android/ndk/wiki
Changelog:
[Android] [Changed] - Android NDK to 26.1
Reviewed By: NickGerleman
Differential Revision: D53083606
fbshipit-source-id: 12290efcfa8a72ab88c21ffe9507d08d5512d61b
Summary:
We are making some decently large changes around here, to transition Fabric away from Yoga's private API, and add new units, and CSS properties. Even confined to Fabric, we have a large matrix of different paths for parsing.
This change consolidates layout props parsing to a single, tested path, used everywhere.
Concretely, this means removing:
1. MapBuffer for ViewProps
2. Iterator style props parsing (for layout props only)
MapBuffer for ViewProps to my understanding is not currently used at all, and has been live to edits, but untested, for quite some time. Iterator style props parsing is still enabled in some configurations, but we don't want to broadly ship its current form, and haven't been able to prioritize shipping it.
Both MapBuffer, and iterator style props parser, are performance wins. If we look at seriously shipping one of these again, we should look at swapping out the current path.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D53072714
fbshipit-source-id: 0a737c8c8f50b1f2c5c0b7ff0415e84a26a06abb
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42673
Fix rendering of textInput using lineHeight in android API level <28 by removing call to ReactEditText.setLineHeight.
ReactEditText.setLineHeight was introduced in API level 28 and we actually don't need to call this method
changelog: [Internal] internal
Differential Revision: D53105649
fbshipit-source-id: f2d81cfea10de84bd47efbfeac1e21837fd49a11
Summary:
If Flow can be trusted, getConstantsForViewManager always gets called with a non-null string:
1. The only call-site to getConstantsForViewManager is getViewManagerConfig: [PaperUIManager.js](https://github.com/facebook/react-native/blob/822bf52c29729d25b2bfb31655cf773609a9283d/packages/react-native/Libraries/ReactNative/PaperUIManager.js#L36-L80)
2. And getViewManagerConfig always passes in a non-null string.
So, let's just make the native argument type a non-nullable string.
Thoughts?
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D52628937
fbshipit-source-id: 0ca68b38253cf134af29974af9e36380d66895a1
Summary:
This API was used by the old architecture to lazily register/load components:
1. Load a ViewManager's class from the disk
2. Register the ViewManager's class with React Native
See: [RCTUIManager lazilyLoadView](https://github.com/facebook/react-native/blob/822bf52c29729d25b2bfb31655cf773609a9283d/packages/react-native/React/Modules/RCTUIManager.m#L1546-L1591)
The new architecture **does not** support lazy loading of **legacy** modules/components.
Therefore, let's leave this API unimplemented until we decide to implement lazy loading of legacy stuff in new architecture.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D52677515
fbshipit-source-id: 8d49a0b54f901a3e9b3e8a9578ebb0c81de522d8
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42434
Changelog: [internal]
The flags for the event loop were set up using different mechanisms due to the limitations of the previous feature flags systems. Now we can centralize on the new system and use them consistently on Android and iOS.
Reviewed By: RSNara
Differential Revision: D52819137
fbshipit-source-id: e30a6f2e12b4a027a906502b80a70dd48bb657b6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42430
This PR creates a new internal feature flags system for React Native. This is only meant to be used internally within the framework, but we might expose it externally in some form in the future to allow customizing specific feature flags in frameworks and applications.
Features:
* 2 types of flags:
* Common: can be overridden from native and are accessible from all layers of the stack (Objective-C/Swift, Java/Kotlin, C++ and JavaScript).
* JS-only: flags that can only be defined and accessed from JS (to allow things like hot reloading without a native build).
* 1 source of truth for each flag.
* Feature flags are application/process scoped (using C++ singletons).
See the `README.md` file in this PR for additional information.
This also adds modifies `run-ci-javascript-tests` to run a new check to make sure that the generate files are in sync with the JSON file that contains the definitions.
Changelog: [internal]
Reviewed By: huntie
Differential Revision: D52806730
fbshipit-source-id: 0ba95803f61ec2f05266ee535921321bf6d3dc6a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42655
This bug is caused by a caching issue: when the user enters a new character into the textInput: ReactTextInput 1) caches the Spannable entered by the user and 2) it updates internal Fabric state, which triggers the measurement of the TextInput component using the cached Spannable.
The problem is that the Spannable entered by the user has the wrong "styles" for the text input. Since measurement is using the cached Spannable, then the measurement of the TextInput ends up being is incorrect.
In this diff I'm fixing the bug by updating the styles (lineHeight) of the cached spannable that is cached when the user updates the TextInput.
The styles weren't updated correctly because mTextAttributes didn't have the proper style props set
Changelog:
[Android][Fixed] - Fix incorrect measurement of TextInput when new architecture is enabled
Reviewed By: javache, sammy-SC
Differential Revision: D52924982
fbshipit-source-id: ced9f2c348bdb9bf706028b1063858cebd5a071a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42659
Those folders for Java don't exist anymore, I'm removing this as it's unnecessary and will default to only src/main/java.
For resources instead, I'm using `setSrcDirs` as it will replace the default, while `srcDirs()` will add those folders.
We need to replace the default res folder as we need to follow the resource folder structure of BUCK
Changelog:
[Internal] [Changed] - Cleanup srcSet for java and res
Reviewed By: cipolleschi
Differential Revision: D53083677
fbshipit-source-id: 4dc42c700ea5446bbd49c63fc43b58ba316f4944
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42600
Disentangled the logic for emitting touches to JS on Android. `receiveTouches` should never be used as a public API, as TouchEvents can be dispatched just like any other event, and receiveTouches is an internal helper for `TouchEvent`.
Changelog: [Android][Removed] Updated migrated guidance for EventEmitter and reduced visibility of internal TouchesHelper methods
Reviewed By: cortinico
Differential Revision: D52907393
fbshipit-source-id: a8207039c863ab23a1d93dd2d2f28e8a274c8ecf
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42660
Calling `maybeLoadSoLibrary` from init is too late, as we call `initHybrid` before `init`. Instead use a static initializer.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D53048065
fbshipit-source-id: dfd2957fd9209e02c498ee08e9cbd7c7a1a83c3e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42657
When the RCT_DEV flag is turned on, we force the eager initialization of the DevMenu at startup.
The initialization was happening in a method of the `CxxBridgeDelegate` protocol.
In bridgeless mode, we don't have the bridge, hence we don't call this method.
I need to put the initialization code in the `RCTIntance` because the only way I found to eagerly initialize a module was to tap into the `RCTTurboModuleManager` and, in Bridgeless mode, that's seemed to be the only way.
I'm open to move the code to a better place, anyway!
## Changelog:
[Internal] - Enable the DevMenu eagerly in Bridgeless mode
Reviewed By: sammy-SC
Differential Revision: D53083637
fbshipit-source-id: 219698eab77ed115ab0f4ea43911ae883a4c9e8a
Summary:
`RCTAttributedTextUtils.mm`: Split `NSAttributedString` creation to functions in preparation for adding new logic here.
This is a minor improvement in the context of my multi-PR work on https://github.com/react-native-community/discussions-and-proposals/issues/695.
## 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
-->
[INTERNAL] [CHANGE] - Refactor `NSAttributedString` creation in `RCTAttributedTextUtils.mm`
Pull Request resolved: https://github.com/facebook/react-native/pull/42595
Reviewed By: cipolleschi
Differential Revision: D53001495
Pulled By: sammy-SC
fbshipit-source-id: 52d28e48f0a9d88d44325a73c64737fc7ac97781
Summary:
Increase the readability of `CustomLineHeightSpan` by making the logic less stateful.
This is a minor improvement in the context of my multi-PR work on https://github.com/react-native-community/discussions-and-proposals/issues/695.
## 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
-->
[INTERNAL] [CHANGED] - Increase the readability of `CustomLineHeightSpan`
Pull Request resolved: https://github.com/facebook/react-native/pull/42592
Test Plan:
- Prove the equivalence of the old and the new logic
- Test that the behavior of `lineHeight` doesn't change
Reviewed By: NickGerleman
Differential Revision: D53028467
Pulled By: mdvacca
fbshipit-source-id: d533bb77c8e10c29d8f2acc8cc39565d0013b03b
Summary:
Changelog: [General][Added] Enable setNativeProps in animations in the New Architecture
Pull Request resolved: https://github.com/facebook/react-native/pull/42603
Enabling setNativeProps in animations on by default.
Reviewed By: mdvacca
Differential Revision: D52962882
fbshipit-source-id: 67921c8e36e97b7b1315dfa0d5f3bd708ccb0079
Summary:
`TextLayoutUtils`: Use named arguments to ensure same-type arguments (like `start`/`end`) are not confused
This is a minor readability follow-up to https://github.com/facebook/react-native/pull/39630.
## 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
-->
[INTERNAL] [CHANGED] - Increase the `TextLayoutUtils` readability slightly
Pull Request resolved: https://github.com/facebook/react-native/pull/42593
Reviewed By: NickGerleman
Differential Revision: D53028402
Pulled By: mdvacca
fbshipit-source-id: 39e99ba70b93eecfc51bda19d30a5b1977cfe406
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42638
Enables these modules to be covered by `public-api-test`.
- Standardise as CommonJS modules, fixing compatibility with [`flow-api-translator`](https://www.npmjs.com/package/flow-api-translator).
- Use explicit object type in generated file template.
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D52963967
fbshipit-source-id: c9f3e35f70859c1b99b7297228ee2498f91d9041
Summary:
With the current ways metro location is determined, when we want to use a different metro port this requires app to be rebuild as the port and location are stored in resource file that gets compiled to R.class. The only way to avoid app rebuild due to a port change is to use shared preferences that can be accessed from dev menu, where metro URL can be specified. However, due to a separate code-paths for retrieving bundle location and for `/inspector/device` calls, the setting only applies to the former. As a consequence, you can change metro URL in the shared preferences, but debugging would only work if you use the default port or you rebuild the app with the correct port number.
This PR removes the separate code-path for retrieving inspector URL including all the dependencies scattered across different files including the gradle plugin. We then replace calls to `PackagerConnectionSettings.getInspectorServerHost` with `PackagerConnectionSettings.getDebugServerHost` which respects the shared preferences and other possible ways of configuring the port.
I decided to remove the separate inspector URL code path, as the resource value for inspector port added in https://github.com/facebook/react-native/issues/23616 was never functioning properly due to a bug. In the said PR introduced a bug in [AndroidInfoHelpers.java](https://github.com/facebook/react-native/blob/a13d51ff1c38ea85e59f4215563c0dd05452f670/packages/react-native/ReactAndroid/src/main/java/com/facebook/react/modules/systeminfo/AndroidInfoHelpers.java#L77) where `react_native_dev_server_port` was used instead `react_native_inspector_proxy_port`. As a result the added resource value was never read.
This can be potentially a breaking change as I'm removing some public methods. However I think it is unlikely anyone relied on said methods. As a part of this PR I'm also changing occurences of removed methods from ReactAndroid.api – I don't know how to test those changes since I don't understand how this file is used as it doesn't have any references in public code.
## Changelog:
[ANDROID] [FIXED] - Make Android respect metro location from shared preferences for the debugger workflow
Pull Request resolved: https://github.com/facebook/react-native/pull/42617
Test Plan:
1. Run android app on emulator using default port
2. Check the debugger works when using "Open Debugger" option from dev menu
3. Restart metro with custom port (`--port 9090`) while keeping the app running
4. Open dev menu, click "Settings" then "Debug server host & port", put "10.0.2.2:9090" there
5. Reload the app
6. Before this change things like hot reload would continue to work while "Open Debugger" option would do nothing
7. After this change both reloading and debugging will work
Important: I haven't tested changes made to ReactAndroid.api as I don't know what this files is used for with no references in the codebase.
Reviewed By: cortinico
Differential Revision: D53010023
Pulled By: huntie
fbshipit-source-id: cc8b9c5c7e834ec9ea02b1ed5acf94f04f7b7116
Summary:
since https://github.com/facebook/react-native/commit/32dab7a63fd0795c3aaefa766aa9f818428ed2de, `DoubleConversion` is now added as an implicit dependency for 3rd party module and it breaks swift integration. this pr tries to add the `DEFINES_MODULE` to DoubleConversion.
## Changelog:
[IOS] [FIXED] - Fixed `DoubleConversion` build error from Swift integration
Pull Request resolved: https://github.com/facebook/react-native/pull/42591
Test Plan:
i'll need to test this on expo latest and react-native nightly build
```sh
# pull latest expo repo and get template tarball
$ git clone --depth 1 https://github.com/expo/expo.git
$ cd expo
$ yarn install
$ cd templates/expo-template-bare-minimum
$ npx pack --pack-destination ../../
# now create an expo app
$ yarn create expo -t blank@sdk-50 sdk50
$ cd sdk50
$ yarn add react-native@nightly
$ jq '.expo.runtimeVersion = { "policy": "appVersion" }' app.json > app.json.tmp && mv app.json.tmp app.json
$ npx expo prebuild -p ios --template /path/to/expo/expo-template-bare-minimum-50.0.17.tgz
$ cd ios
$ pod install
```
then it will show the error message:
```
[!] The following Swift pods cannot yet be integrated as static libraries:
The Swift pod `ExpoModulesCore` depends upon `DoubleConversion`, which does not define modules. To opt into those targets generating module maps (which is necessary to import them from Swift when building as static libraries), you may set `use_modular_headers!` globally in your Podfile, or specify `:modular_headers => true` for particular dependencies.
```
Reviewed By: cortinico
Differential Revision: D53048352
Pulled By: cipolleschi
fbshipit-source-id: b1e27d3d26e8543a4cb2e8062c93c68543a051c5
Summary:
This PR removes the `apply_ats_config` function of ReactNativePodsUtils that was used inside `react_native_post_install` because it was preventing users from configuring `NSAllowsArbitraryLoads` to true in their projects, especially when building in CI as the plist file would be reset after running pod install.
## Changelog:
[IOS] [CHANGED] - Remove ATS config patch from react_native_post_install
Pull Request resolved: https://github.com/facebook/react-native/pull/42637
Test Plan: Edit `Info.plist`, run `pod install` and check if changes have not been overwritten
Reviewed By: cortinico
Differential Revision: D53048299
Pulled By: cipolleschi
fbshipit-source-id: 8dc335fae2e05a62daf931a50fa3f7a314e76a2e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42639
When I reverted part of the deprecation of `RCT_NEW_ARCH_ENABLED`, I forget a little bit which was breaking RCTFabric podspec.
This diff fixes that.
## Changelog:
[Internal] - Bring back `RCT_NEW_ARCH_ENABLED` to Fabric to make the `RCTThirdPartyFabricComponentsProvider` work again.
Reviewed By: cortinico
Differential Revision: D53048270
fbshipit-source-id: d21e833c10b332fb70147cc65b690f88016655e6
Nick Gerleman
Samuel Susla
Riccardo Cipolleschi
Ilia Vorobev
HoonJoo
szymonrybczak
Dmitry Rykun
Alex Hunt
Blake Friedman
Rob Hogan
David Vacca
Phillip Pan
Kevin Gozali
Wojciech Lewicki
Jakub Trzebiatowski
Rubén Norte
Ramanpreet Nara
Nicola Corti
Pieter De Baets
Krzysztof Magiera
Kudo Chien
Gabriel Donadel