Summary:
Fixed a link in a comment that lead to dead link
whatwg-url changed the source directory from `lib` to `src`
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://github.com/facebook/react-native/wiki/Changelog
-->
[INTERNAL] [FIXED] - fix dead link in a comment
Pull Request resolved: https://github.com/facebook/react-native/pull/31902
Test Plan: - [ ] Changed URL opens properly
Reviewed By: charlesbdudley
Differential Revision: D29915170
Pulled By: lunaleaps
fbshipit-source-id: 00b69db82f51d16cf887cd4540a159132ad7d771
Summary:
1. [ios] upgrade folly to 2021.06.28.00 which aligned to android.
2. folly compile setting from c++14 -> c++17: _this folly requires c++17 for `std::unordered_map::insert_or_assign`._
3. boost 1.63.0 -> 1.76.0: _the old boost does not support c++17._
4. deprecating react-native-community/boost-for-react-native: _by cocoapods installer, we could download the official target._
## Changelog
[iOS] [Changed] - Upgrade folly to 2021.06.28.00 and boost to 1.76.0
Pull Request resolved: https://github.com/facebook/react-native/pull/31840
Test Plan: CI passed
Reviewed By: fkgozali
Differential Revision: D29668480
Pulled By: yungsters
fbshipit-source-id: 98eae9ca47f489dcea91974e6f5e9dcb4d66c40c
Summary:
This migrates all ObjC NativeModule setBridge: calls to the bridge compatible initialize: call. I filtered out ViewManagers.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D28595520
fbshipit-source-id: b0e5dd681fb3563894f1aa3da1728f0c694f04bb
Summary:
Updating the regex to avoid a potential regular expression denial-of-service vulnerability.
Changelog: Update validateBaseUrl to use a more robust regular expression. Fixes CVE-2020-1920, GHSL-2020-293
Reviewed By: lunaleaps
Differential Revision: D25507604
fbshipit-source-id: c36a03c456881bc655c861e1a2c5cd41a7127c9d
Summary:
This fixes an error where folly fails to build on Xcode 12.5, by bumping the various folly deps in RN to builds with a fix.
Next step is to commit this to 0.64 release branch
allow-large-files
Changelog: [iOS] Fix builds on Xcode 12.5
Reviewed By: fkgozali
Differential Revision: D28071808
fbshipit-source-id: 236b66bf8294db0c76ff25b11632c1bf89525921
Summary:
This intentionally leaks the static map, since it still might be accessed after static destructors are run. This is a common approach to this problem, see https://github.com/facebook/react-native/pull/22607 and https://github.com/facebook/componentkit/pull/906 as examples. It also sets up an autorelease pool from `RCTNativeModule::invoke` as a precaution since there's no strict guarantee one exists when it is called.
Changelog:
[iOS][Fixed] - Fix crash in RCTCoreModulesClassProvider during quit
Reviewed By: RSNara
Differential Revision: D27932062
fbshipit-source-id: fa75da4b78290027a762440ac6943c81b8594a57
Summary:
CocoaPods will display a "fatal: not a git repository" when these podspecs are consumed within Facebook's internal Mercurial repository due to the reliance on `git` to obtain the current commit hash.
In these cases, the podspec is being consumed locally and the commit hash is unnecessary.
The error is removed by avoiding the use of `git` if the current working directory is not a git repository (or any of the parent directories).
Changelog:
[Internal] [iOS] - Remove CocoaPods error within Facebook's repository
Reviewed By: fkgozali
Differential Revision: D27750974
fbshipit-source-id: 99159611c580baf5526f116948c5ff60e1c02e5c
Summary:
After installed a third party library I just got "Error: not implemented" without any other informations in the stack trace. Adding a more specific sentence within the error's message can be useful to understand what is going on.
## Changelog
[General] [CHANGED] - Added context to URL's error messages when the feature is not implemented
Pull Request resolved: https://github.com/facebook/react-native/pull/31237
Differential Revision: D27367109
Pulled By: PeteTheHeat
fbshipit-source-id: 87e8b3beef661e028d89098729bd242a57bb9a47
Summary:
ES Modules implicitly enable strict mode. Adding the "use strict" directive is, therefore, not required.
This diff removes all "use strict" directives from ES modules.
Changelog:
[Internal]
Reviewed By: motiz88
Differential Revision: D26172715
fbshipit-source-id: 57957bcbb672c4c3e62b1db633cf425c1c9d6430
Summary:
All NativeModules that used to use the bridge to require other NativeModules now require other NativeModules via the Venice-compatible RCTModuleRegistry abstraction. Therefore, we can safely get rid of synthesize bridge = _bridge from them.
## How did I generate this diff?
1. Search for all NativeModules that have `synthesize bridge =`
2. Remove the `synthesize bridge = _bridge` from each NativeModule, and if it doesn't contain `_bridge`, `setBridge:`, or `elf.bridge`, add it to this codemod.
Changelog: [Internal]
Reviewed By: PeteTheHeat
Differential Revision: D25551295
fbshipit-source-id: 585d50ad55cb9ab083e430b07e1cf30e31f0d3c5
Summary:
RCTBlobManager actually has the name "BlobModule", not "BlobManager".
Changelog: [Internal]
Reviewed By: PeteTheHeat
Differential Revision: D25569865
fbshipit-source-id: f6b41300bda6485cef3f18d3d0308dad9c002b77
Summary:
All NativeModules that use `[RCTBridge moduleForClass:]` to access other NativeModules are now instead using the Venice-compatible RCTModuleRegistry to access other NativeModules.
Changelog: [Internal]
Reviewed By: shergin
Differential Revision: D25508277
fbshipit-source-id: 1b415a5ad4055290940879e100ceaa84ae83feeb
Summary:
All NativeModules that access the _bridge from self to require the WebSocketModule NativeModule now instead get the WebSocketModule NativeModule from the _moduleRegistry.
Changelog: [Internal]
Reviewed By: PeteTheHeat
Differential Revision: D25500433
fbshipit-source-id: 21aebc5684dd6a058de4e35b042c9fb255ffcb33
Summary:
All NativeModules that access the _bridge from self to require the Networking NativeModule now instead get the Networking NativeModule from the _moduleRegistry.
NOTE: xbgs .networking reveal any other usages. So, there won't be a manual migration diff associated with this codemod.
Changelog: [Internal]
Reviewed By: PeteTheHeat
Differential Revision: D25499412
fbshipit-source-id: 7b0e33135c6c91ffc1e041ad3ab95f1346a8bc22
Summary:
While investigating a bridgeless networking issue, I noticed something very peculiar. **Two** networking turbo modules are built and used in bridgeless mode. Upon debugging, I realized that each of them have a different `TurboModuleHolder`. The reason is the following:
1. In JS, the module's name is [Networking](https://fburl.com/diffusion/f2xu4wie)
2. In ObjC, we call the module "RCTNetworking" (examples in this diff)
3. Both scenarios end up creating the correct Turbo Module: [RCTNetworking](https://www.internalfb.com/intern/diffusion/FBS/browsefile/master/xplat/js/react-native-github/Libraries/Network/RCTNetworking.mm?link_ref=search), but the `TurboModuleHolder` doesn't know that "RCTNetworking" and "Networking" are the same. Any other modules accessed this way will have the same issue.
An alternative solution would be to tell `TurboModuleHolder` to strip the `RCT` suffix, which would solve the problem globally. RSNara thoughts?
Changelog: [Internal]
Reviewed By: RSNara
Differential Revision: D25477044
fbshipit-source-id: 02219de578ef4d19e579110e4242883a30cefcd6
Summary:
This should be a noop. It just makes writing codemods easier.
Changelog: [Internal]
Reviewed By: PeteTheHeat
Differential Revision: D25442218
fbshipit-source-id: dba0c35a6f566e83ed5b7142075fff6929efeada
Summary:
Changelog: [internal]
In D25386708 (408bcdeedb) `synthesize bridge` was removed. But two modules actually depend on this.
`RCTFileReaderModule` and `VerseThreadView` which both use it.
Reviewed By: RSNara
Differential Revision: D25423574
fbshipit-source-id: daf95d9b27841cf8d205d8ea2666d5aa69a6d720
Summary:
This is a codemod. All these NativeModules demand access to the bridge. However, they don't use it.
Changelog: [Internal]
Reviewed By: PeteTheHeat, RoelCastano
Differential Revision: D25386708
fbshipit-source-id: f05f4777d2527e96e53581e7ac58f6be47411dce
Summary:
Refs: [0.62 release](https://reactnative.dev/blog/#moving-apple-tv-to-react-native-tvos), https://github.com/facebook/react-native/issues/28706, https://github.com/facebook/react-native/issues/28743, https://github.com/facebook/react-native/issues/29018
This PR removes most of the tvOS remnants in the code. Most of the changes are related to the tvOS platform removal from `.podspec` files, tvOS specific conditionals removal (Obj-C + JS) or tvOS CI/testing pipeline related code.
In addition to the changes listed above I have removed the deprecated `Platform.isTVOS` method. I'm not sure how `Platform.isTV` method is correlated with Android TV devices support which is technically not deprecated in the core so I left this method untouched for now.
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://github.com/facebook/react-native/wiki/Changelog
-->
* **[Internal] [Removed]** - remove most of tvOS remnants from the code:
* `TVEventHandler`, `TVTouchable`, `RCTTVView`, `RCTTVRemoteHandler` and `RCTTVNavigationEventEmitter`
* **[Internal] [Removed]** - remove `TARGET_TV_OS` flag and all the usages
* **[iOS] [Removed]** - remove deprecated `Platform.isTVOS` method
* **[iOS] [Removed]** - remove deprecated and TV related props from View:
* `isTVSelectable`, `hasTVPreferredFocus` and `tvParallaxProperties`
* **[iOS] [Removed]** - remove `BackHandler` utility implementation
Pull Request resolved: https://github.com/facebook/react-native/pull/29407
Test Plan: Local tests (and iOS CI run) do not yield any errors, but I'm not sure how the CI pipeline would react to those changes. That is the reason why this PR is being posted as Draft. Some tweaks and code adjustment could be required.
Reviewed By: PeteTheHeat
Differential Revision: D22619441
Pulled By: shergin
fbshipit-source-id: 9aaf3840c5e8bd469c2cfcfa7c5b441ef71b30b6
Summary:
Fixes iOS builds failing with the following error in certain setups:
```
/~/Pods/React-RCTBlob/Libraries/Blob/RCTBlobPlugins.mm:14:9: fatal error: 'RCTBlobPlugins.h' file not found
#import "RCTBlobPlugins.h"
^~~~~~~~~~~~~~~~~~
1 error generated.
```
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://github.com/facebook/react-native/wiki/Changelog
-->
[iOS] [Fixed] - "'RCTBlobPlugins.h' file not found" when building iOS
Pull Request resolved: https://github.com/facebook/react-native/pull/29684
Test Plan:
- Existing builds should not fail
- Tested this change internally where we are seeing this build failure
cc hramos
Reviewed By: fkgozali
Differential Revision: D23581090
Pulled By: appden
fbshipit-source-id: 89d2088c362bfbd22df5cd098b110a43d76e784f
Summary:
Microsoft’s RN for macOS fork supports the Hermes engine nowadays https://github.com/microsoft/react-native-macos/pull/473. As a longer term work item, we’ve started moving bits that are not invasive for iOS but _are_ a maintenance burden on us—mostly when merging—upstream. Seeing as this one is a recent addition, it seemed like a good candidate to start with.
As to the actual changes, these include:
* Sharing Android’s Hermes executor with the objc side of the codebase.
* Adding a CocoaPods subspec to build the Hermes inspector source and its dependencies (`Folly/Futures`, `libevent`).
* Adding the bits to the Xcode build phase script that creates the JS bundle for release builds to compile Hermes bytecode and source-maps…
* …coincidentally it turns out that the Xcode build phase script did _not_ by default output source-maps for iOS, which is now fixed too.
All of the Hermes bits are automatically enabled, on macOS, when providing the `hermes-engine-darwin` [npm package](https://www.npmjs.com/package/hermes-engine-darwin) and enabling the Hermes pods.
## Changelog
[General] [Added] - Upstream RN macOS Hermes integration bits
Pull Request resolved: https://github.com/facebook/react-native/pull/29748
Test Plan:
Building RNTester for iOS and Android still works as before.
To test the actual changes themselves, you’ll have to use the macOS target in RNTester in the macOS fork, or create a new application from `master`:
<img width="812" alt="Screenshot 2020-08-18 at 16 55 06" src="https://user-images.githubusercontent.com/2320/90547606-160f6480-e18c-11ea-9a98-edbbaa755800.png">
Reviewed By: TheSavior
Differential Revision: D23304618
Pulled By: fkgozali
fbshipit-source-id: 4ef0e0f60d909f3c59f9cfc87c667189df656a3b
Summary:
## Why?
1. RCTTurboModuleLookupDelegate sounds a bit nebulous.
2. In JS and Java, we use a `TurboModuleRegistry` interface to require TurboModules. So, this diff will make JS, Java, and ObjC consistent.
Changelog:
[Internal]
Reviewed By: PeteTheHeat
Differential Revision: D22405754
fbshipit-source-id: 30c85c246b39d198c5b8c6ca4432a3196ca0ebfd
Summary: TurboModules doesn't cache invocations of getConstants(). This diff looks at which NativeModules' getConstants() methods gets repeated called in Marketplace, and caches those invocations in JS.
Reviewed By: fkgozali
Differential Revision: D21874123
fbshipit-source-id: a44b98b3ac8621f67c9c0f3b7c4003a561d1e15d
Summary:
## Problem
For some reason, D20831545 broke the `use_frameworks!` build of RNTester.
## Building RNTester
```
pushd ~/fbsource/xplat/js/react-native-github/RNTester && USE_FRAMEWORKS=1 pod install && open RNTesterPods.xcworkspace && popd;
```
## Error
I built RNTester locally, and the error was this:
```
Undefined symbols for architecture x86_64:
"facebook::jsi::HostObject::set(facebook::jsi::Runtime&, facebook::jsi::PropNameID const&, facebook::jsi::Value const&)", referenced from:
vtable for facebook::react::ObjCTurboModule in RCTImageEditingManager.o
vtable for facebook::react::ObjCTurboModule in RCTImageLoader.o
vtable for facebook::react::ObjCTurboModule in RCTImageStoreManager.o
"facebook::jsi::HostObject::getPropertyNames(facebook::jsi::Runtime&)", referenced from:
vtable for facebook::react::ObjCTurboModule in RCTImageEditingManager.o
vtable for facebook::react::ObjCTurboModule in RCTImageLoader.o
vtable for facebook::react::ObjCTurboModule in RCTImageStoreManager.o
ld: symbol(s) not found for architecture x86_64
```
## Fix
It looked like libraries that depend on "ReactCommon/turbomodule/core" weren't linking to JSI correctly. So, I modified all such Podspecs to also depend on "React-jsi":
```
arc rfr ' s.dependency "ReactCommon/turbomodule/core", version' ' s.dependency "ReactCommon/turbomodule/core", version\n s.dependency "React-jsi", version'
```
This seemed to do the trick. In buck, we'd fix this problem using exported_dependencies. I skimmed through cocoapods, and couldn't find such a configuration option there. So, I guess this will have to do?
Changelog:
[iOS][Fixed] - Fix Cocoapods builds of RNTester
Reviewed By: fkgozali, hramos
Differential Revision: D20905465
fbshipit-source-id: 60218c8274ec165752a428f2a7a9a546607c8fec
Summary:
This gets us on the latest Prettier 2.x:
https://prettier.io/blog/2020/03/21/2.0.0.html
Notably, this adds support for TypeScript 3.8,
which introduces new syntax, such as `import type`.
Reviewed By: zertosh
Differential Revision: D20636268
fbshipit-source-id: fca5833d003804333a05ba16325bbbe0e06d6c8a
Summary:
## Description
In T63516227, we're seeing a crash that occurs because `networking.methodQueue` is `nil`, and we try to `dispatch_async` to it.
## Hypothesis
This looks like a problem with NativeModule cleanup:
1. Some JS executes a call to `RCTBlobManager.addNetworkingHander`. This schedules an async method call on the `RCTBlobManager` method queue.
2. In `RCTCxxBridge invalidate`, on the JS thread, we loop through all the `RCTModuleData`s, and invalidate them. This invalidates our NativeModules (perhaps not all but only `RCTNetworking`).
3. The `RCTBlobManager.addNetworkingHander` method call finally executes, with `RCTNetworking`'s methodQueue set to nil, which throws this error.
Changelog:
[iOS][Fixed] - Fix RCTBlobManager cleanup crash
Reviewed By: PeteTheHeat
Differential Revision: D20498096
fbshipit-source-id: d2d60984637ddf883278289258aa9b2ae81bb172
Summary:
We recently updated React Native's docs site to have its own domain reactnative.dev and needed to update the URLs in the source code
CHANGELOG:
[INTERNAL]
Reviewed By: hramos
Differential Revision: D20072842
fbshipit-source-id: 1970d9214c872a6e7abf697d99f8f5360b3b308e
Summary:
In `XMLHttpRequest`, if the responseType is `Blob`, but the response is an empty string, we return `null` from `XMLHttpRequest.prototype.response()`. Instead, we should return an empty Blob. This is the behaviour on the web. To demonstrate, run the following HTTP server with Node:
## server.js
```
const http = require('http');
const server = http.createServer();
server.on('request', (request, response) => {
if (request.url.includes('img.png')) {
console.log('sending image');
response.end('');
return;
}
response.end('Hello World!');
});
server.listen('9000');
```
Then, open up a web browser to `http://localhost:9000`, and type the following in the console:
```
var oReq = new XMLHttpRequest();
oReq.open('GET', 'http://localhost:9000/img.png', true);
oReq.responseType = 'blob';
oReq.onload = function(oEvent) {
var blob = oReq.response;
console.warn(blob);
};
oReq.onerror = function(error) {
console.warn('Error!');
};
oReq.send();
```
This warns:
```
Blob {size: 0, type: "text/xml"}
```
Changelog:
[Both][Fixed] - [RN][XMLHttpRequest] Transform empty responses into empty Blobs
Reviewed By: sahrens
Differential Revision: D19500607
fbshipit-source-id: ec35e534b32a507c8a94a29e955b7bc4c62902a0
Summary:
When bridge is nil, RCTBlobManager crashes with `EXC_BAD_ACCESS`.
The fix: instead of using the bridge to find RCTNetworking, use TM lookup delegate.
Changelog: [iOS][Internal] Fix crash in RCTBlobManager in bridgeless mode
Reviewed By: mdvacca
Differential Revision: D19320136
fbshipit-source-id: 49aabb3ce53b2ec620fcc02be1c6c1b44066f440
Summary:
It is time to target SDK version 10.0+.
Changelog: [iOS] [Deprecated] - Deprecating support for iOS/tvOS SDK 9.x, 10.0+ is now required
Reviewed By: mdvacca
Differential Revision: D19265731
fbshipit-source-id: 93b6f9e8f61c5b36ff69e80d3f18256aa96cc2c0
Summary:
It's possible for us to return no constants from the BlobModule. Therefore, I'm correcting the flow-type.
Changelog:
[Internal]
Reviewed By: fkgozali
Differential Revision: D18932328
fbshipit-source-id: 2b415d12effd16eda313d5591825c711a20f9ae3
Summary:
We are rolling out exact-by-default syntax to xplat/js.
I had to manually move around some comments to preserve proper placement.
Changelog: [Internal]
Reviewed By: jbrown215
Differential Revision: D18633611
fbshipit-source-id: 48f7468dcc55b1d00985419d035a61c6820b3abe
Summary:
Changelog: [Internal]
Reverting the import to the previous local module style since importing from react-native seems to introduce some perf regression. We'll revisit this later in the future.
Reviewed By: yungsters
Differential Revision: D18383893
fbshipit-source-id: f11d46a4545768f39199fd6fd22fcf14905d0a74
Summary:
Changelog: [Internal]
Moved the imports for `TurboModuleRegistry` and `TurboModule` from `react-native`. This was a jscodeshift with the script: P120688078
Reviewed By: yungsters
Differential Revision: D18262538
fbshipit-source-id: 48fac15229c897408928511c5ecbb42f17ec7b42
Summary:
I kept on running `USE_FRAMEWORKS=1 update-pods && open RNTesterPods.xcworkspace` and adding missing dependencies until `RNTesterPods` started compiling without failure.
**Note:** I made sure to only commit the podfile changes from `update-pods`, **without** `USE_FRAMEWORKS=1`.
Changelog:
[iOS][Fixed] - Fix all RN Podspecs
Reviewed By: fkgozali
Differential Revision: D18284535
fbshipit-source-id: 44d288ae0e52dd2cbbe26bebe7df73ce05644b5d
Summary: We generate a stub for plugin system, so that TurboModules can work in OSS. Unless the `RN_DISABLE_OSS_PLUGIN_HEADER` define is seet, TurboModules will use the plugin stub. Therefore, for internal builds, we should set this define.
Reviewed By: fkgozali, mdvacca
Differential Revision: D17789993
fbshipit-source-id: a93735738513457236adb3064b80601053c95dd3