Summary:
I suggest we grab our own version of worker-farm, since there are a few changes we'd like to do. There are two reasons for forking:
* the original project does not seem maintained anymore, with a PR remaining unanswered (https://github.com/rvagg/node-worker-farm/pull/42);
* we don't need to keep the level of genericity of the original project: for example, we don't need the option `maxConcurrentCallsPerWorker`, that we always keep to one.
Forking gives us opportunity to simplify the code for our use case. Later on we could reuse it for other projects such as `jest`.
A few things we'd like to do:
* remove special node options from the forks, such as `--inspect`, or even, allow adding special options (if you want to debug a worker specifically for example);
* allow us to pipe `stdout` and `stderr` instead of having transform spit stuff out to the parent process output;
* remove code managing `maxConcurrentCallsPerWorker` and clean up the code in general;
* add `flow` typing.
Reviewed By: davidaurelio
Differential Revision: D4993300
fbshipit-source-id: 10f0c2a18b010c2a8b2e2afebcb3aab3504d7923
Summary:
Moves the `YGLogger` into `YGConfig` and pass the `YGNodeRef` into the logger to be able to associate the log messages and assertions with the specific node.
Tackles facebook/yoga#530 and facebook/yoga#446
Closes https://github.com/facebook/yoga/pull/531
Reviewed By: astreet
Differential Revision: D4970149
Pulled By: emilsjolander
fbshipit-source-id: b7fcdaa273143ea2fa35861620b2e4d79f04f0af
Summary:
Resolve path at callsite rather than in `Config.loadFile`
`Config.loadFile` should not expose unexpected behavior as joining paths together. This moves that responsibility to the call site. `path.resolve` returns the second argument if it is an absolute path.
Reviewed By: bestander
Differential Revision: D4986130
fbshipit-source-id: c80a588ffa86011bcd5a2c393ad5d6eedc6c61ae
Summary: `cwd` was needed for FB-internal reasons, was untyped, and goes away.
Reviewed By: martinbigio
Differential Revision: D4986076
fbshipit-source-id: b093476cabc4f73fb63d37052f4041073c174f06
Summary:
Splits `ConfigT` into `ConfigT` (core + packager configuration) and `RNConfig` (RN CLI configuration).
Also guarantees that all values on `ConfigT` have a default when loading user configuration.
Reviewed By: jeanlauliac
Differential Revision: D4985965
fbshipit-source-id: bf036e22d6809e49746a9c3aa240ec403a085342
Summary: `no-alert` doesn’t play nice with flow type spreads. We don’t need it for node, anyway.
Reviewed By: jeanlauliac
Differential Revision: D4993096
fbshipit-source-id: 95785843d3263520c063a43864c8053cbaa5083d
Summary:
`declareOpts` prevents strong Flow typing, and promotes default values, that may be different from a function to another (my goal is to remove defaults from the whole codebase except perhaps the public API). This changeset replaces it by Flow types and fixes callsites to be explicit on values.
This is the last callsite of `declareOpts` so I'll remove it, in a separate diff.
Reviewed By: cpojer
Differential Revision: D4970650
fbshipit-source-id: e5ea2e06febde892d28c9dc59dc2920d4033bb01
Summary:
Gets rid of `Config.get` in favor of three methods with names that express intend. The logic for applying defaults was used from one callsite only, and was moved there.
This is the starting point to make the config loading system a better place, including a strong return type and defaults always applied.
Reviewed By: martinbigio
Differential Revision: D4985774
fbshipit-source-id: 98300547c3eafd5948814d57ce93e71d43572eb8
Summary:
The new implementation of z-index did not handle touches properly. This fixes it by using the mapped child index like we do in `getChildDrawingOrder` in `TouchTargetHelper`.
**Test plan**
Tested that touchables work properly inside sticky headers (it uses z-index) on Android.
Closes https://github.com/facebook/react-native/pull/13705
Reviewed By: AaaChiuuu
Differential Revision: D4987964
Pulled By: sahrens
fbshipit-source-id: 165f98e23d2f304c4dc87f536c22b68a8923d806
Summary: Separates the polyfills used for node.js from the configuration of `babel-register`, to make pretransforming packager before invoking it easier.
Reviewed By: cpojer
Differential Revision: D4978047
fbshipit-source-id: 45d3d49d0a714a8257be8d244a01e41b68bbce3d
Summary:
When using a translucent status bar using `<StatusBar />` and a `<Modal transparent />` the dialog layer applies its own translucent status bar color on top causing the status bar to darken.
This is especially problematic when the modal is a menu and nothing on the screen is supposed to darken.
I've collected screenshots of the status bar in various situations before and after this change to show the change and demonstrate that it doesn't have any bad side effects for the other status bar and modal types (non-translucent status bars / non-transparent modals).
* "**Before**" row: RN 0.43.1 unmodified
* "**After**" row: This modification applied
* **Translucent**: Translucent status bar `<StatusBar backgroundColor='rgba(0, 0, 0, 0.2)' translucent />` (modal closed)
* **Alpha Colored**: Coloured translucent status bar `<StatusBar backgroundColor='rgba(255, 0, 255, 0.2)' translucent />` (modal closed)
* **Not Translu...**: Non-translucent status bar `translucent={false}` (modal closed)
* **w/modal**: Same as image to the left but with the Modal opened
* **Opaque Modal**: Translucent status bar with open but opaque/dim modal (`<Modal transparent={false} />`)
![Screenshot Matrix](https://cloud.githubusercontent.com/assets/53399/25305992/d4bca728-2739-11e7-8801-a31424e3bf50.png)
Closes https://github.com/facebook/react-native/pull/13629
Differential Revision: D4985349
Pulled By: astreet
fbshipit-source-id: 4d3614a07bb15cb52f220d9444b898d15be7b4dc
Summary: People rarely re-order sections so this is an annoying requirement and we can just use the index by default.
Reviewed By: thechefchen
Differential Revision: D4972154
fbshipit-source-id: 256c445b36c9ba101277614d30a6dc1dbd477ee0
Summary: The xcode project for these bundled libraries should not depend on UIExplorer
Reviewed By: yungsters
Differential Revision: D4979629
fbshipit-source-id: 440b225805e9ebaf0a02b39a35c3ab9c2a83ad05
Summary:
`contentSize` was removed from both iOS and Android, tests was updated.
USE `onContentSizeChange` INSTEAD.
Why?
* It always was a hack;
* We already have dedicated event for it: `onContentSizeChange`;
* `onChange` has nothing to do with layout actually;
* We have to maintain `onChange` handler as fast and simple as possible, this feature complicates it a lot;
* It was undocumented feature;
* We already have native auto-expandable <TextInput>, so it illuminates 99% current use cases of this feature.
Reviewed By: mmmulani
Differential Revision: D4680300
fbshipit-source-id: 337836deef0767e5f26350f5a8ce73adb4146a02
Summary: Fixes support for haste packages in `ModuleGraph`. As `HasteMap` is no longer used for anything else, we can probably strip it down completely.
Reviewed By: cpojer
Differential Revision: D4967367
fbshipit-source-id: d40cbe46c1e8b05690c0a2c71955479c28607c01
Summary: deduplicates / unifies types for source maps across the code base
Reviewed By: jeanlauliac
Differential Revision: D4955924
fbshipit-source-id: 25cb71031dce835dd7d2bc1c27d6b20050906e81
Summary:
Two things in there:
* Using `base64` was kinda broken, as it can contain slashes, invalid in file names. It would still work however because it would just create a second level folder when doing `mkdirp`. Still I think it's better to fix that correctness.
* Include the UID in the hash, so that different users have different folders for sure, and that we reduce potiential permissions issues. `tmpdir()` already returns a folder that's user-specific on OS X, but this is not a guarantee on all platforms.
Reviewed By: cpojer
Differential Revision: D4969856
fbshipit-source-id: 4a9be35104ac9698edf2c84c58d395ee171ce2a8
Summary: Oftentimes packager stalls for several seconds after requiring a bundle, because it's busy cleaning up old cache files. We shouldn't do that when, for example, we just restarted packager. This changeset stores the micro-timestamp of the last collection so that we don't waste time next time.
Reviewed By: cpojer
Differential Revision: D4969832
fbshipit-source-id: 3aa0495b18d5a8efa1b8f87dbf7a40b0673fd9fd
Summary:
Fixes the sizing of items so that under most scenarios it calcultes its height by it's content for non exact measurings. This introduces a new useLegacyStretchBehaviour flag on the config to opt out of this change as it is breaking.
See facebook/yoga#505
Closes https://github.com/facebook/yoga/pull/506
Reviewed By: astreet
Differential Revision: D4954016
Pulled By: emilsjolander
fbshipit-source-id: d28bd5d174cd76951fb94df85e3b0cfab7f81ff7
Summary:
Added an example of the Fetch usage inside a component.
Thanks for submitting a pull request! Please provide enough information so that others can review your pull request:
> **Unless you are a React Native release maintainer and cherry-picking an *existing* commit into a current release, ensure your pull request is targeting the `master` React Native branch.**
Explain the **motivation** for making this change. What existing problem does the pull request solve?
Prefer **small pull requests**. These are much easier to review and more likely to get merged. Make sure the PR does only one thing, otherwise please split it.
**Test plan (required)**
Demonstrate the code is solid. Example: The exact commands you ran and their output, screenshots / videos if the pull request changes UI.
Make sure tests pass on both Travis and Circle CI.
**Code formatting**
Look around. Match the style of the rest of the codebase. See also the simple [style guide](https://github.com/facebook/react-native/blob/master/CONTRIBUTING.md#style-guide).
For more info, see the ["Pull Requests" section of our "Contributing" guidelines](https://github.com/facebook/react-native/blob/master/CONTRIBUTING.md#pull-requests).
Closes https://github.com/facebook/react-native/pull/12348
Differential Revision: D4962419
Pulled By: hramos
fbshipit-source-id: 37b3517811f5391126d9e3ec026d2902705729a7
Summary:
Updated map view example to correct and extend on change event management
Thanks for submitting a pull request! Please provide enough information so that others can review your pull request:
> **Unless you are a React Native release maintainer and cherry-picking an *existing* commit into a current release, ensure your pull request is targeting the `master` React Native branch.**
Explain the **motivation** for making this change. What existing problem does the pull request solve?
Prefer **small pull requests**. These are much easier to review and more likely to get merged. Make sure the PR does only one thing, otherwise please split it.
**Test plan (required)**
Demonstrate the code is solid. Example: The exact commands you ran and their output, screenshots / videos if the pull request changes UI.
Make sure tests pass on both Travis and Circle CI.
**Code formatting**
Look around. Match the style of the rest of the codebase. See also the simple [style guide](https://github.com/facebook/react-native/blob/master/CONTRIBUTING.md#style-guide).
For more info, see the ["Pull Requests" section of our "Contributing" guidelines](https://github.com/facebook/react-native/blob/master/CONTRIBUTING.md#pull-requests).
Closes https://github.com/facebook/react-native/pull/12759
Differential Revision: D4962286
Pulled By: hramos
fbshipit-source-id: 92cc41f100616d3b5633603cf69850ebc9fc33b2
Summary:
I don't think editing the search path is necessary anymore for notifications since [0.40](https://github.com/facebook/react-native/releases/tag/v0.40.0).
I removed the part that says to edit the search paths, and changed `#import "RCTPushNotificationManager.h"` to `#import <React/RCTPushNotificationManager.h>` in the documentation
Thanks for submitting a PR! Please read these instructions carefully:
- [ ] Explain the **motivation** for making this change.
- [ ] Provide a **test plan** demonstrating that the code is solid.
- [ ] Match the **code formatting** of the rest of the codebase.
- [ ] Target the `master` branch, NOT a "stable" branch.
What existing problem does the pull request solve?
A good test plan has the exact commands you ran and their output, provides screenshots or videos if the pull request changes UI or updates the website. See [What is a Test Plan?][1] to learn more.
If you have added code that should be tested, add tests.
Sign the [CLA][2], if you haven't already.
Small pull requests are much easier to review and more likely to get merged. Make sure the PR does only one thing, otherwise please split it.
Make sure all **tests pass** on both [Travis][3] and [Circle CI][4]. PRs that break tests are unlikely to be merged.
For more info, see the ["Pull Requests"][5] section of our "Contributing" guidelines.
[1]: https://medium.com/martinkonicek/what-is-a-test-plan-8bfc840ec171#.y9lcuqqi9
[2]: https://code.facebook.com/cla
[3]: https://travis-ci.org/facebook/react-native
[4]: http://circleci.com/gh/facebook/react-native
[5]: https://github.com/facebook/react-native/blob/master/CONTRIBUTING.md#pull-requests
Closes https://github.com/facebook/react-native/pull/13700
Differential Revision: D4969728
Pulled By: javache
fbshipit-source-id: d72aee1c5b8578cea27d6b7d45ee7a7f269433fc