Summary:
* Added snapToOffsets prop to ScrollView. Allows snapping at arbitrary points.
* Fixed pagingEnabled not being overridden by snapToInterval on iOS.
* Fixed Android *requiring* pagingEnabled to be defined alongside snapToInterval.
* Added support for decelerationRate on Android.
* Fixed snapping implementation. It was not calculating end position correctly at all (velocity is not a linear offset).
* Resolves https://github.com/facebook/react-native/issues/20155
* Added support for new content being added during scroll (mirrors existing functionality in vertical ScrollView).
* Added support for snapToInterval.
* Resolves https://github.com/facebook/react-native/issues/19552
Reviewed By: yungsters
Differential Revision: D9405703
fbshipit-source-id: b3c367b8079e6810794b0165dfdbcff4abff2eda
Summary: A bunch of flows including JS reload and e2e tests seem to hit the race condition, causing redbox. For now, make it a warning to unblock.
Differential Revision: D9327418
fbshipit-source-id: a72b378d88f7566268fd9415fbd34225c8b931e7
Summary:
This pull request adds the ability for a platform developer to provide a `"haste"` key under the `"rnpm"` key in their `package.json` which allows the packager to pick up that platform's javascript files. The intent is to remove the need to have custom platforms hardcoded in. This is inspired by the `"jest": { "haste": {} }` key used by jest.
For example, React Native Dom would have an entry like:
```json
{
"rnpm": {
"haste": {
"providesModuleNodeModules": [
"react-native-dom"
],
"platforms": [
"dom"
]
}
}
}
```
Support for more keys (path blacklists perhaps?) could be added in the future.
This succeeds #20662, as per a discussion I had with matthargett.
I've got an open discussion over here as well: https://github.com/react-native-community/discussions-and-proposals/issues/21
Pull Request resolved: https://github.com/facebook/react-native/pull/20825
Differential Revision: D9596429
Pulled By: hramos
fbshipit-source-id: a02f0da0bea8870bdc45d55e23da8ccbc36249f2
Summary: This diff fixes a couple of edge cases that caused Metro to keep the process running when there were some specific errors (specially around the `dependencies` command and the transformer path).
Reviewed By: jrwats
Differential Revision: D9551834
fbshipit-source-id: 959cefcec9e2687dff89c94a871ae74c50d2dd77
Summary: Now that babel7 is stable, we can upgrade Metro and fbsource to use it, yay!!!!!
Reviewed By: mjesun
Differential Revision: D9518571
fbshipit-source-id: c85569cb3058235f4f9310949897f7955ecf7324
Summary: D9070810 introduced a breaking change, making the `--transformer` CLI argument able to override the generic transformer instead of `babelTransformer`. Since we still have some scripts that assume `--transformer` is being used for overriding the babelTransformer path, we cannot do this breaking change yet, so this diff reverts the CLI handling to the old behaviour.
Reviewed By: jrwats
Differential Revision: D9550157
fbshipit-source-id: 8b4e26fcb5bca6e4b2f63b1e1a014bce23a31452
Summary:
This diff exposes the new more generic way to configure transformers in `Metro` via the config parameter `transformerPath`.
The new generic transformers can be used to transform any kind of file, since they don't call any JS-specific method and their API is generic. They only need to implement a single `transform` method:
```
async function transform(
absolutePath: string,
relativePath: string,
fileContents: Buffer,
options: TransformOptions, // very soon these will be configurable
): Promise<{
output: Array<mixed>,
dependencies: Array<{
name: string,
data: mixed, // very soon
}>,
}> {
// ...
}
```
Metro already had a `transformModulePath` config param, which was used to configure how babel was called in order to generate the AST. In order to avoid confusion, but keep the current open source transformer worker, I've renamed this param to `babelTransformerPath`. We can add a layer of compatibility and detect old config params in order to show a deprecation warning.
Reviewed By: pvdz
Differential Revision: D9070810
fbshipit-source-id: aebde879736026c09537f5d236eae24c06640abf
Summary:
This diff exposes the new more generic way to configure transformers in `Metro` via the config parameter `transformerPath`.
The new generic transformers can be used to transform any kind of file, since they don't call any JS-specific method and their API is generic. They only need to implement a single `transform` method:
```
async function transform(
absolutePath: string,
relativePath: string,
fileContents: Buffer,
options: TransformOptions, // very soon these will be configurable
): Promise<{
output: Array<mixed>,
dependencies: Array<{
name: string,
data: mixed, // very soon
}>,
}> {
// ...
}
```
Metro already had a `transformModulePath` config param, which was used to configure how babel was called in order to generate the AST. In order to avoid confusion, but keep the current open source transformer worker, I've renamed this param to `babelTransformerPath`. We can add a layer of compatibility and detect old config params in order to show a deprecation warning.
Reviewed By: pvdz
Differential Revision: D9070810
fbshipit-source-id: aebde879736026c09537f5d236eae24c06640abf
Summary:
This is the first step to make transformers fully customizable (and not be tied to JS, or RN). In order to do that, I'm changing the signature of the transformers, which currently is:
```
function transformCode(
filename: string,
localPath: LocalPath,
transformerPath: string,
options: WorkerOptions,
assetExts: $ReadOnlyArray<string>,
assetRegistryPath: string,
minifierPath: string,
asyncRequireModulePath: string,
dynamicDepsInPackages: DynamicRequiresBehavior,
)
```
to be:
```
async function transformCode(
filename: string,
localPath: LocalPath,
options: WorkerOptions,
)
```
(so basically, all the RN-custom properties are moved to `WorkerOptions`, which in the future will be a generic to allow anybody pass any random option to their transformers).
In order to make all this work, I've had to get rid of the logic that calculates the base cache key hash based on a subset of worker options (the ones that Metro knows that are not going to change between runs).
This could potentially cause a perf regression (since we're now making the hash calculation a bit more costly), and in fact I could measure a ~400ms regression on the worse case scenario (which happens when restarting Metro and re-transforming a Wilde from a warm local cache).
I've benchmarked this regression and could find that it's caused by the array of `assetExtensions` (which is potentially large). I have a followup diff to improve this, which is able to remove the regression completely.
Reviewed By: pvdz
Differential Revision: D8695766
fbshipit-source-id: eccd18a4cbc91854f34d5c9ba7f95088f19483a1
Summary:
While the original reason for this change was because of an issue #20780, with further investigation I concluded that the issue is till present for this combo of versions:
glog - 0.3.5
google-cast-sdk - 4.3.1
Downgrading google-cast-sdk to 4.3.0 fixed the build issue.
Release Notes:
--------------
Updated glog version from 0.3.4 to 0.3.5 for iOS
[IOS] [ENHANCEMENT] [GLOG]
Pull Request resolved: https://github.com/facebook/react-native/pull/20811
Differential Revision: D9485221
Pulled By: hramos
fbshipit-source-id: 65caf0839588384a5229a6165506dc6ef62e5fc5
Summary:
There are some steps known to be failing on master. This pollutes checks for unrelated PRs.
This PR will make it so that PRs submitted by anyone other than myself will no-op on these steps.
Future work: Have an array of whitelisted contributors, and make it much easier to turn individual tests on and off.
Pull Request resolved: https://github.com/facebook/react-native/pull/20818
Differential Revision: D9484946
Pulled By: hramos
fbshipit-source-id: d6c187b341f13552b33d0f1d569b65f6c66ae48f
Summary:
This pull request addresses the failing publish-npm.js script from earlier this week. For background, last month we reset all npm access tokens for any package related to Facebook, and we now require all accounts with publish permissions to have two factor enabled.
The publish-npm.js script relied on one such token that is configured in Circle CI as a envvar. The token has been updated in Circle CI, but we now need a way of passing the one time password to npm.
With this PR, we can now grab the otp from Circle CI's envvars. Considering otps are ephemeral, this requires the NPM_CONFIG_OTP envvar to be set by someone with publishing permissions anytime a new release will be pushed to npm. The token is short lived, but it would still be good to clear the envvar after the package is published. Circle CI envvars are not passed on to PR/forked builds.
This PR is effectively a breaking change for the release process, as the publish step will not succeed if the OTP is not valid.
OTPs are short-lived, and the publish_npm_package job will definitely outlive the token. Unfortunately this will require some timing to get right, but the alternative is to ssh into the Circle CI machine and re-run the `npm publish --otp` command, which again would still require someone with publish access to provide the otp.
Pull Request resolved: https://github.com/facebook/react-native/pull/20701
Differential Revision: D9478488
Pulled By: hramos
fbshipit-source-id: 6af631a9cb425271b98c03d158aec390ebc95304
Summary:
Bump android gradle plugin to 3.1.4. We have been stay to 2.x too long. With 3.x we can have instant run and great performance and new features brought by google.
Also thanks to CFKevinRef great pr to make this possible.
pass all current ci. I have also tested RNTester release version works without crash.
https://github.com/facebook/react-native/pull/17967.
[GENERAL] [ANDROID] [FEATURE] - bump android gradle to 3.1.4
Pull Request resolved: https://github.com/facebook/react-native/pull/20767
Differential Revision: D9437576
Pulled By: hramos
fbshipit-source-id: 6084056a1390582a75a879918f2538b0480f6299
Summary:
This PR removes TextLayoutBuilder, which is not used anywhere.
Pull Request resolved: https://github.com/facebook/react-native/pull/20600
Reviewed By: achen1
Differential Revision: D9367345
Pulled By: hramos
fbshipit-source-id: 407a6a80f5c69650fcc7167b28214f7315beed2f
Summary:
This PR removes infer-annotation from the repo and uses latest version of it from maven.
Pull Request resolved: https://github.com/facebook/react-native/pull/20599
Differential Revision: D9437594
Pulled By: hramos
fbshipit-source-id: 93c33041dd8a61b220c352fb187a23bb2dd1b4db
Summary:
Fixes#20769
Release notes
--------------
[CLI] [BUGFIX] [local-cli/server/checkNodeVersion.js] - Disable auto-formatting in `local-cli/server/checkNodeVersion.js` since it introduces ES6 and ES7 syntax (trailing comma in argument list) which in turn makes ES5 engines crash with a `SyntaxError`.
Pull Request resolved: https://github.com/facebook/react-native/pull/20779
Differential Revision: D9468346
Pulled By: hramos
fbshipit-source-id: 24761a377a5fd104e11ed6b6e86da15e96a0e38b
Summary:
@public
This diff fixes the `projectRoot` calculation on React Native when the app does not have a config file. This should fix the issues reported in https://github.com/facebook/react-native/issues/20712
Reviewed By: hramos
Differential Revision: D9444982
fbshipit-source-id: 4cb41fa5224d2addf92976cc119e49dea6a6346b
Summary:
We have several disabled tests in Circle, and they are not running at all.
This prevents us from seeing when a disabled test might actually be fixed, as enabling the test requires uncommenting the correct line in Circle CI's config.
In this PR, we use the existing swallow_error script to run known-failing steps, without failing the job. This will let us see the step's output in CI, without polluting PRs that have not introduced new failures to CI.
Pull Request resolved: https://github.com/facebook/react-native/pull/20775
Differential Revision: D9442412
Pulled By: hramos
fbshipit-source-id: 83c930811a559fdcf6d7b926b4073343e862d2b3
Summary:
Commit 79e498b7fb claims that "--terminal" has been added as an argument to the "run-android" script which it hasn't. Instead it adds a new environment variable "process.env.REACT_TERMINAL" which seems to be undocumented and nowhere else in the repository.
This commit now allows Linux and OSX users to specify their custom terminal :
react-native run-android --terminal=x-terminal-emulator
Additionally the metro bundler child process "detached" option has been set to false if no terminal has been specified on Linux which fixes an issue where the packager would be running in the background and would have to manually be closed by finding the process.
Fixes#18122
Pull Request resolved: https://github.com/facebook/react-native/pull/20584
Differential Revision: D9234990
Pulled By: hramos
fbshipit-source-id: 60e4cc57b2790c419d5a4f9027add04313ddf6f8
Summary:
Per [this comment on the issue](https://github.com/facebook/react-native/issues/20710#issuecomment-414631827):
> Babel by default tries to find .babelrc files to configure itself, and once it finds the one from the RN app (which links to the RN preset that only works on Babel 7) it fails.
> The easiest patch to fix this issue is to add babelrc: false to the babel-register method, so Babel does not read any additional .babelrc file.
Fixes#20710
Pull Request resolved: https://github.com/facebook/react-native/pull/20790
Differential Revision: D9458502
Pulled By: hramos
fbshipit-source-id: 3a0ed7261322fdd9e0c0840f8a3944974f38b233
Summary:
@public
We can't dynamically link `WebKit` because doing so will impact cold start of all our Apps.
This diff includes a few changes:
1. Weakly link the `WebKit` framework in the `ReactInternal` library, so that the compiler doesn't die when it encounters a WebKit symbol.
2. Undo dynamic linking of WebKit in Catalyst.
3. Undo dynamic linking of WebKit in AdsManager
4. Before the first `WKWebView` is instantiated, dynamically load the `WebKit` framework.
The end result of these changes is that WebKit will be loaded only when it's going to be used.
Reviewed By: mmmulani
Differential Revision: D6564328
fbshipit-source-id: a45a44e774d0c61c1fb578a6fa3d16bb08f68ac9
Summary:
@public
The `WKWebView` class doesn't expose a `scalesPageToFit` property, unlike `UIWebView`. Therefore, the `scalesPageToFit` RN prop is be a bit tricky to implement with `WKWebView`.
For the time being, this diff adds warnings to `<WebView/>` whenever `useWebKit={true}` and `scalesPageToFit` is set. I've also updated the documentation to reflect that we don't support `scalesPageToFit` prop with the new implementation of `<WebView/>`.
Reviewed By: shergin
Differential Revision: D6429271
fbshipit-source-id: adf858cb67ba221c70d6d6f1bd6cff505e90c365
Hector Ramos
Mike Grabowski
Oleg LokhvitskyandMike Grabowski
Kevin GozaliandLorenzo Sciandra
empyricalandLorenzo Sciandra
Rafael OlezaandLorenzo Sciandra
Vladimir ZdravkovicandHector Ramos
gengjiawenandHector Ramos
DulmandakhandLorenzo Sciandra
Sergei DryganetsandLorenzo Sciandra
Elias ToivanenandHector Ramos
Héctor RamosandHector Ramos
jamschandHector Ramos
Nick GraefandHector Ramos
Ramanpreet NaraandLorenzo Sciandra