Summary:
**Depends on https://github.com/facebook/react-native/pull/25100**
This is one of the steps unlocked by migrating RN from Haste to path-based imports. This commit sets Flow to use path-based imports by removing all of the Haste-related configuration options.
Additionally, it maps `react-native` to import from within this module to match Node's module resolution behavior. It also adds `<PROJECT_ROOT>` to the image name mapper so that the mapped name doesn't rely on Haste.
## Changelog
[General] [Changed] - Make Flow configs use path-based imports instead of Haste
Pull Request resolved: https://github.com/facebook/react-native/pull/24812
Differential Revision: D15659189
Pulled By: cpojer
fbshipit-source-id: d0efaa2884485a492dcdef8d94061129cebc2566
Summary:
**Depends on https://github.com/facebook/react-native/pull/25100**
This commit depends on having migrated all of RN away from Haste. With 100% standard path-based requires, the key foundation is set and we no longer need `hasteImpl` and related settings in the Jest configuration.
This commit deletes the `hasteImpl` file and setting as well as `providesModuleNodeModules` and `modulePathNameMapper`, removing most of the dependency graph overriding performed by Jest.
## Changelog
[General] [Changed] - Delete hasteImpl, providesModuleNodeModules, and modulePathNameMapper from Jest config
Pull Request resolved: https://github.com/facebook/react-native/pull/24811
Differential Revision: D15659274
Pulled By: cpojer
fbshipit-source-id: 8a4a3b97ddf7e38fbe62c6d3cc9c98248bfca343
Summary:
### Problem
According to https://github.com/facebook/react-native/issues/9145, the `--port` setting is not respected when executing `react-native run-android`. The templates that report things like what port the dev server runs on are hard coded as well.
### Solution
This commit replaces the hardcoded instances of port 8081 on Android with a build configuration property. This allows setting of the port React Native Android connects to for the local build server.
For this change to work, there must also be an update to the react native CLI to pass along this setting:
https://github.com/react-native-community/react-native-cli/compare/master...nhunzaker:9145-android-no-port-hardcode-cli
To avoid some noise on their end, I figured I wouldn't submit a PR until it's this approach is deemed workable.
## Changelog
[Android][fixed] - `react-native run-android --port <x>` correctly connects to dev server and related error messages display the correct port
Pull Request resolved: https://github.com/facebook/react-native/pull/23616
Differential Revision: D15645200
Pulled By: cpojer
fbshipit-source-id: 3bdfd458b8ac3ec78290736c9ed0db2e5776ed46
Summary:
Tests file exposed in 608b1b5ea2. This break e2e tests, so let's excluded them from JSI pod.
## Changelog
[iOS] [Fixed] - Excluded tests file from JSI pod
Pull Request resolved: https://github.com/facebook/react-native/pull/25151
Differential Revision: D15645046
Pulled By: cpojer
fbshipit-source-id: 19c712e4307cf712b8377d721661a2b476151732
Summary:
Fixes#18177 . Related #24497. Autoresizing mask would conflict with `AutoLayout`. For example , it would impact `SafeAreaView`. And actually we don't need to use autoresizing mask, we observe the bounds change notification and [update the frame manually](1151c096da/React/Views/RCTModalHostView.m (L59)).
## Changelog
[iOS] [Fixed] - Removed autoresizing mask for modal host container view
Pull Request resolved: https://github.com/facebook/react-native/pull/25150
Differential Revision: D15645148
Pulled By: cpojer
fbshipit-source-id: 95d5f40feaa980b959a3de6e273dccac8158c57b
Summary:
**This is a manual React sync to replace Haste names with paths so that the removal of Haste is not blocked on a normal React sync. This is a one-time special case; in the future, React will generate renderers that use paths instead of Haste.**
This commit uses the same base commit of React that's currently in RN (React ec6691a68716bc59291746fc62f374a56fb435c9) plus a commit in the React repo that removes Haste-style imports from the renderer (61f62246c8cfb76a4a19d1661eeaa5822ec37b36) and a commit to make the shims import from `implementations` (https://github.com/facebook/react/pull/15786).
I built React in the React repo with `yarn build` and copied over the `oss` directory into one called `implementations` and removed the `*.fb.js` files.
## Changelog
[General] [Changed] - Sync React with Haste-style imports rewritten to use path-based imports instead
Pull Request resolved: https://github.com/facebook/react-native/pull/25100
Reviewed By: yungsters
Differential Revision: D15575646
Pulled By: cpojer
fbshipit-source-id: adf25f9826b71729043b65ba1afd20d14d8c19c4
Summary:
And, btw, the tests show that performance of that is not so great:
```
Running /Users/shergin/fbsource/fbobjc/buck-out/cells/fbsource/gen/xplat/js/react-native-github/ReactCommon/fabric/core/benchmarks
Run on (12 X 2900 MHz CPU s)
CPU Caches:
L1 Data 32K (x6)
L1 Instruction 32K (x6)
L2 Unified 262K (x6)
L3 Unified 12582K (x1)
--------------------------------------------------------------------------------------------
Benchmark Time CPU Iterations
--------------------------------------------------------------------------------------------
propParsingUsingComponentDescriptor 79630 ns 77991 ns 8864
propParsingUsingComponentDescriptorWithNoSourceProps 70200 ns 69099 ns 8362
```
Which means 70ms per 1000 prop parsing processes.
Reviewed By: JoshuaGross, mdvacca
Differential Revision: D15608677
fbshipit-source-id: ed4feca489e1243adc73de4741c287256c3aaec3
Summary:
First of all, seems it's the right thing to do. Fabric C++ code is cross-platfrom and should run on *all* platforms including Windows, Linux, and Mac.
While we don't have a real *production* use cases where we need compilation for desktops, having CXX target is really handy for two reasons:
* It simplifies local test running process. Instead of going to `/fbandroid/` and executing something like `buck test fbsource//xplat/js/react-native-github/ReactCommon/fabric/core:coreAndroid` (note the suffix). We can just do `buck test fbsource//xplat/js/react-native-github/ReactCommon/fabric/core:core` everywhere and it works now out of the box. Running tests with "Apple" flavor never worked for me.
* It allows creating synthetic benchmark tests (using Google Benchmark) that can be used as a rough approximation of code micro-optimizations.
Reviewed By: JoshuaGross
Differential Revision: D15608678
fbshipit-source-id: d2449035685dbca6ab983480f5334ec4ac11cd35
Summary: This adds the testlib.cpp/h files to external JSI. They're in a `test/` subdirectory so that build scripts using globs like `*.cpp` won't include them.
Reviewed By: mhorowitz
Differential Revision: D15582281
fbshipit-source-id: 1785ee5071fcf98e92fbf3a11eddb21fe84b3799
Summary:
In 2019-6-4 version of Docker Android image, we've added Android NDK r19c. So this PR will change CI to use NDK r19c.
I'll create a PR to website once this merged.
Note: I tried to build RN with NDK 19 while I was setting up my laptop after format, and it worked.
## Changelog
[Android] [Changed] - Bump Android NDK to r19c
Pull Request resolved: https://github.com/facebook/react-native/pull/25140
Differential Revision: D15631301
Pulled By: cpojer
fbshipit-source-id: b9a5600df1dadeba328932b694493960b242c2f7
Summary:
In environments with McAfee EPro software, port 8081 is used and cannot be unbound. (See [#20466](https://github.com/facebook/react-native/issues/20466) for a recent example issue.) Most issues can be worked around by passing a `--port` option or setting `RCT_METRO_PORT`, but there are a couple places where 8081 is hardcoded that block adoption. Right now the workaround I've seen pushed on Stack Overflow and elsewhere is to modify node_modules after a `yarn install`, so I'd like to fix it at the source.
This PR changes the react "Start Packager" build step and some code in the iOS DevSupport library to read from the `RCT_METRO_PORT` variable.
## Changelog
[General] [Changed] - Removed hardcoded references to port 8081 and replaced them by reading from RCT_METRO_PORT (w/ fallback to 8081)
Pull Request resolved: https://github.com/facebook/react-native/pull/25144
Differential Revision: D15630119
Pulled By: cpojer
fbshipit-source-id: aff5d24691e0e9892a035cfbd25330fed6441199
Summary:
Fixes build in Xcode 11 beta, the signature for `__unused` was changed. This adds a new check for the new style.
## Changelog
[iOS] [Fixed] - Xcode 11 beta build
Pull Request resolved: https://github.com/facebook/react-native/pull/25146
Differential Revision: D15628404
Pulled By: cpojer
fbshipit-source-id: 781a188a0e1562a3316fbe62920b12b03a44e4a7
Summary:
With JSI based architecture, there will be more and more C++ native code involved.
Original NDK builder in RN only supports release build and that's not reasonable for native debugging.
This change introduces a way to build native code in debuggable version.
Simply add `NATIVE_BUILD_TYPE=Debug` environment variable during gradle build,
e.g.
`NATIVE_BUILD_TYPE=Debug ./gradlew clean :ReactAndroid:assembleDebug`
## Changelog
[Android] [Added] - Add native debug build support to improve debugging DX
Pull Request resolved: https://github.com/facebook/react-native/pull/25147
Differential Revision: D15628533
Pulled By: cpojer
fbshipit-source-id: 8f5b54c4580824452d2a1236a7bd641889b001ec
Summary: `TurboModuleManagerDelegate` is an interface used to query/create TurboModules. It doesn't need to know anything about `ReactApplicationContext`. So, I'm removing all references of `ReactApplicationContext` from this class.
Reviewed By: mdvacca
Differential Revision: D15590552
fbshipit-source-id: 761d3ed71f124955f9c6b997e68a7a8338182126
Summary:
The accessibilityActions accessors in UIView+React.m are not aligned with the property declaration in the header file.
## Changelog
[General] [Fixed] - Fix accessibilityActions accessors
Pull Request resolved: https://github.com/facebook/react-native/pull/25134
Differential Revision: D15621848
Pulled By: cpojer
fbshipit-source-id: f344689292ae7988e46d0d4263980306d364366b
Summary: Before we flow-typed NativeI18nManager, we defaulted the implementation of I18nManager to something safe when it wasn't available. After the flow-type, it became a requirement that NativeI18nManager be present in the app. This is leading to crashes: T45287329. This diff re-enables the defaults for I18nManager.
Reviewed By: fkgozali
Differential Revision: D15617660
fbshipit-source-id: c3a1c737663a1a4ceae484d0ad6cbf2bd86ffe5f
Summary: Right now we render a surface by calling `AppRegistry.runApplication`, but the way we do this relies on the batched bridge. For Venice (bridgeless RN) I created a new module for registering a surface called SurfaceRegistry, which uses a global variable instead of registering itself as a callable module on the bridge. If that global variable exists, we can use that to start the surface instead of calling AppRegistry.
Reviewed By: sahrens
Differential Revision: D15502241
fbshipit-source-id: 0b8d4677f1df41f46d84444567a30e40e21fed3d
Summary: The `_rctTurboModuleCache` `std::unordered_map` can be accessed by multiple threads at the same time via the `provideRCTTurboModule` method. Since `provideRCTTurboModule` both reads and writes to `_rctTurboModuleCache`, this is really bad because we could end up reading from `_rctTurboModuleCache` while it's in an invalid state. Therefore, in this diff, I'm making it so that only one thread at a time can enter `provideRCTTurboModule`.
Reviewed By: fkgozali
Differential Revision: D15609987
fbshipit-source-id: e24e1f5cc2351d8cbb820b7a97074aacd06eec9d
Summary: Move PtrJNodeMap to header file so that it can be accessed in events subscribers outside yoga
Reviewed By: davidaurelio
Differential Revision: D15602627
fbshipit-source-id: bb5bd5bbf8dcb279f5f87a4fd7287909d4e895d8
Summary:
unistd.h isn't a header available in the windows SDK, so we can't include it from react-native-windows.
I moved the usage of dup, to JSBigString.cpp in a previous PR, so this header should only be needed in the cpp file, not the header. (And react-native-windows doesn't use the cpp file)
## Changelog
[Internal] [Fixed] - Header cleanup
Pull Request resolved: https://github.com/facebook/react-native/pull/25107
Differential Revision: D15602265
Pulled By: cpojer
fbshipit-source-id: 6a62bf8fe6758e400810f37834e8646485120d71
Summary:
I noticed that the RNTester-tvOS target is not compilable when I wanted to test the TVOS capacity of React Native.
More specifically, the changes included in this PR are:
### RNTester-tvOS target
1. Add `AppDelegate.mm` to the target.
2. Add `.m` files under `turbomodule` to the target.
3. Add the following directories to **header search path**.
```
$(SRCROOT)/../third-party/boost_1_63_0
$(SRCROOT)/../third-party/folly-2018.10.22.00
$(SRCROOT)/../third-party/glog-0.3.5/src
```
4. Add `RN_BUNDLE_PREFIX` to the scheme argument.
5. Add `RN_BUNDLE_PREFIX` entry to the plist file.
### React-tvOS target
1. Add `RCTCxxBridgeDelegate.h` and `JSCExecutorFactory.h` to the **Copy headers**.
## Changelog
[iOS] [Fixed] - Fixed the issue that the RNTester-tvOS is not compilable.
Pull Request resolved: https://github.com/facebook/react-native/pull/25110
Differential Revision: D15602450
Pulled By: cpojer
fbshipit-source-id: e7eda18c8193b7d88355feafa69043ffef4a8edb
Summary: This diff adds support for ColorArrayValue in the flow parser
Reviewed By: cpojer
Differential Revision: D15502923
fbshipit-source-id: 6a906b6d609168378fabeb49d0080de011a34d78
Summary:
Co-Authored: zamotany
With React Native 0.59.8 the app keeps crashing with indexed RAM bundle on Android with the following error:
```
2019-05-09 11:58:06.684 2793-2856/? E/AndroidRuntime: FATAL EXCEPTION: mqt_js
Process: com.ramtestapp, PID: 2793
com.facebook.jni.CppException: getPropertyAsObject: property '__fbRequireBatchedBridge' is not an Object
no stack
at com.facebook.react.bridge.queue.NativeRunnable.run(Native Method)
at android.os.Handler.handleCallback(Handler.java:873)
at android.os.Handler.dispatchMessage(Handler.java:99)
at com.facebook.react.bridge.queue.MessageQueueThreadHandler.dispatchMessage(MessageQueueThreadHandler.java:29)
at android.os.Looper.loop(Looper.java:193)
at com.facebook.react.bridge.queue.MessageQueueThreadImpl$4.run(MessageQueueThreadImpl.java:232)
at java.lang.Thread.run(Thread.java:764)
```
After investigation we found that when using any bundle, let it be non-ram, FIle RAM bundle or Index RAM bundle, the `CatalystInstanceImpl.java` is always using `loadScriptsFromAsset`, which is calling `CatalystInstanceImpl::jniLoadScriptFromAssets` in C++. This method when checking if bundle is a RAM bundle, uses `JniJSModulesUnbundle::isUnbundle` which only check for js-modules/UNBUNDLE - file generated when building File RAM bundle. There is no other logic to handle Indexed RAM bundle, so it figures that the bundle is not RAM, cause there is no js-modules/UNBUNDLE file and tries to load as regular bundle and fails.
In this PR we added check if it is indexed RAM bundle in `jniLoadScriptFromAssets` and handle it if it is.
## Changelog
[Android] [Fixed] fix indexed RAM bundle
Solves https://github.com/facebook/react-native/issues/21282
Pull Request resolved: https://github.com/facebook/react-native/pull/24967
Differential Revision: D15575924
Pulled By: cpojer
fbshipit-source-id: 5ea428e0b793edd8242243f39f933d1092b35260
Summary:
We need to use second for calculation, so change 17ms to 0.017s instead.
## Changelog
[iOS] [Fixed] - Fixes wrong time unit of scroll event throttle
Pull Request resolved: https://github.com/facebook/react-native/pull/25098
Reviewed By: sahrens, cpojer
Differential Revision: D15576526
Pulled By: sammy-SC
fbshipit-source-id: ddd8dd9098cbe582c6923ce8466892c363c090fc
Summary: This diff creates the base classes for MapBuffer and its tests
Reviewed By: shergin
Differential Revision: D15550730
fbshipit-source-id: a5a47edebd7c3e1b8b2c3ad2006aee0f8bdb7866
Summary: It used a wrong name, so this fixed the module lookup.
Reviewed By: yungsters
Differential Revision: D15595099
fbshipit-source-id: f5a711f595d9630541ae08339aa1532ed1d4d5f2
Summary:
Previously we tried to fix that with RCTUnsafeExecuteOnUIManagerQueueSync but that caused a deadlock (yeah, it's actually unsafe).
Besides that, I tried to solve that with introducing a mutex that covers access to `_operations` and `_preOperations` but failed miserably. It solved threading issue but that didn't fix data-races and inconsistency of the collections.
Reviewed By: sahrens
Differential Revision: D15587564
fbshipit-source-id: d1953036b09354d1663a9b191440f8b4a4e6be9d
Summary:
While ViewConfig infra isn't perfect we need to check that for correcness.
See the task for more details.
Reviewed By: JoshuaGross
Differential Revision: D15578675
fbshipit-source-id: c99c2be9c215e6b9d7ee8e6e50d85e822c1f007e
Summary: When metro is not running, D15559151 caused infinite exceptions (fetch threw an error if it couldn't connect to localhost:8081) which affected UI. Swallow those errors and everything works well, with or without metro.
Reviewed By: yungsters
Differential Revision: D15588623
fbshipit-source-id: d170ea82478545836a7a22a228196c9778e93ef0
Summary: Some callsites access `UIManager` from `NativeModules.UIManager` instead of importing directly from `UIManager.js`. Post TurboModule spec flow typing, we don't install `getViewManagerConfig()` on the NativeUIManager object anymore, only on the JS wrapper. So callsites not importing from `UIManager.js` will break. Example: dbf746d66c/lib/components/decorateMapComponent.js (L32-L40)
Reviewed By: JoshuaGross, mdvacca
Differential Revision: D15588353
fbshipit-source-id: 2c2b497dae0660abf15acb2f944546fe03e9bb0a
Summary:
The `test_end_to_end` job has been timing out due CocoaPods taking too long to check out the Specs repo. This repo is stored at `~/.cocoapods`, therefore by caching this folder we can keep the individual e2e test run from exceeding 10 minutes w/o output.
## Changelog
[Internal] [Added] - Cache CocoaPods
Pull Request resolved: https://github.com/facebook/react-native/pull/25095
Differential Revision: D15587702
Pulled By: hramos
fbshipit-source-id: 6669ff09a5021f012ac8a829db70442d8f7f07e8
Summary:
This PR fixes incorrect unhooking for UI manager views in `RCTProfileUnhookModules`. `view` is actually a key, not the view itself; instead, use `viewForReactTag:` to obtain the view itself.
This fixes issue #24952.
## Changelog
[iOS] [Fixed] - Fix incorrect unhooking for UI manager views in `RCTProfileUnhookModules`, causing an infinite `RCTProfileTrampoline ` recursion (#24952)
Pull Request resolved: https://github.com/facebook/react-native/pull/25042
Differential Revision: D15580978
Pulled By: PeteTheHeat
fbshipit-source-id: 3483a7f6380b6fb1db4249374d86f692348c9aa2
Summary: This continues the migration off of haste for react-native-github by changing `react-native-implementation` not to use haste.
Reviewed By: JoshuaGross
Differential Revision: D15575896
fbshipit-source-id: 0de7314b7d038a6d603d09ca910f84d580c5cc33
James Ide
Rick Hanlon
Nate
zhongwuzw
Kody Greenbaum
Joshua Gross
Valentin Shergin
Will Holen
Dulmandakh
Jim Berlage
Eric Lewis
Kudo Chien
Ramanpreet Nara
Sharon Gong
Tim Yung
Sam Goldman
Emily Janzer
Sidharth Guglani
Alex Cohen
REDMOND\acoates
Hermanyo
Bruno Lemos
spdr admin
Dratwas
Michael Mason
David Vacca
Kevin Gozali
mitulsavani
Héctor Ramos
Oleg Lokhvitsky
David Aurelio
Leo Natan
Christoph Nakazawa