Summary:
This kills fastfs in favor of Jest's hasteFS. It gets rid of a ton of code, including the mocking code in ResolutionRequest which we don't need any more. Next step after this is to rewrite HasteMap, ModuleCache, Module/Package. We are getting closer to a nicer and faster world! :)
Here is what I did:
* Use Jest's HasteFS instead of fastfs. A fresh instance is received every time something changes on the FS.
* HasteFS is not shared with everything any more. Only one reference is kept in DependencyGraph and there are a few smaller functions that are passed around (getClosestPackage and dirExists). Note: `dirExists` now does fs access instead of an offline check. This sucks but stat calls aren't slow and aren't going to be a bottleneck in ResolutionRequest, I promise! When it is time to tackle a ResolutionRequest rewrite with jest-resolve, this will go away. "It gets worse before it gets better" :) The ModuleGraph equivalent does *not* do fs access and retains the previous way of doing things because we shouldn't do online fs access there.
* Add flow annotations to ResolutionRequest. This required a few tiny hacks for now because of ModuleGraph's duck typing. I'll get rid of this soon.
* Updated ModuleGraph to work with the new code, also created a mock HasteFS instance there.
* I fixed a few tiny mock issues for `fs` to make the tests work; I had to add one tiny little internal update to `dgraph._hasteFS._files` because the file watching in the tests isn't real. It is instrumented through some function calls, therefore the hasteFS instance doesn't get automatically updated. One way to solve this is to add `JestHasteMap.emit('change', …)` for testing but I didn't want to cut a Jest release just for that. #movefast
(Note: I will likely land this in 1.5 weeks from now after my vacation and I have yet to fully test all the product flows. Please give me feedback so I can make sure this is solid!)
Reviewed By: davidaurelio
Differential Revision: D4204082
fbshipit-source-id: d6dc9fcb77ac224df4554a59f0fce241c01b0512
Summary: Flow was updated in bf901d926ece75057391ffaf6ce47e70ad107525, need to update the config file for the template too.
Reviewed By: mkonicek
Differential Revision:
D4240152
Ninja: OSS tests only
fbshipit-source-id: c20704c43a5d603105125a0316b7926cdc7cd7fd
Summary:
The upgrading process based on Yeoman is a pain. For each file, Yeoman (or the brand new copyAndReplace solution a477aec) compares the newly generated content with the existing one and prompts the user if it differs, with very basic options: overwrite or skip.
I have digged into this problem and came with [rn-diff](https://github.com/ncuillery/rn-diff) (you may have read [this article](https://medium.com/ncuillery/easier-react-native-upgrades-with-rn-diff-5020b5c3de2d#.llvy2dym5)). This repository helps people to upgrade RN on their projects. An alternative upgrading process using `git apply` instead of Yeoman is described [here](https://github.com/ncuillery/rn-diff/blob/master/USAGE.md).
This PR is the integration of this process into the core. I got rid of the drawbacks mentioned in the link below in order to make it a clean, elegant, one-step operation.
This process is based on some Shell operations that:
- Generate the blank sources of both old and new versions
Closes https://github.com/facebook/react-native/pull/11110
Differential Revision: D4237107
Pulled By: mkonicek
fbshipit-source-id: 15e82e030b762415c925ccb2a62ddb354a6e18b9
Summary:
Instead of exposing a `getTransformOptionsModulePath` function in configurations, we can simply expose a `getTransformOptions` *function*. The necessity of exposing a path comes from the olden days, where we had a server listening on a socket, and a client, talking to that server.
Since that architectural gem no longer exists, we can use functions directly, rather than passing paths to modules around.
Reviewed By: cpojer
Differential Revision: D4233551
fbshipit-source-id: ec1acef8e6495a2f1fd0911a5613c144e8ffd7c3
Summary:
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?
Warning about new Buffer when init
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#s
Closes https://github.com/facebook/react-native/pull/11153
Differential Revision: D4234591
fbshipit-source-id: a9373f3151de8a50c18342f45fb9684a5c7416a6
Summary:
This removes support for `require('image!…')`, which has been deprecated for a long time.
It is still possible to use images that are already bundled by the native app using the `nativeImageSource` module.
Check http://facebook.github.io/react-native/docs/images.html for detailed documentation.
Reviewed By: matryoshcow
Differential Revision: D4231208
fbshipit-source-id: 05ec4c1ca0fabdc3fbb652f8ad1acdf240a67955
Summary:
To make React Native play nicely with our internal build infrastructure we need to properly namespace all of our header includes.
Where previously you could do `#import "RCTBridge.h"`, you must now write this as `#import <React/RCTBridge.h>`. If your xcode project still has a custom header include path, both variants will likely continue to work, but for new projects, we're defaulting the header include path to `$(BUILT_PRODUCTS_DIR)/usr/local/include`, where the React and CSSLayout targets will copy a subset of headers too. To make Xcode copy headers phase work properly, you may need to add React as an explicit dependency to your app's scheme and disable "parallelize build".
Reviewed By: mmmulani
Differential Revision: D4213120
fbshipit-source-id: 84a32a4b250c27699e6795f43584f13d594a9a82
Summary:
Follow up to #8190
Tested with custom parameter as well as w/o (using default value). All worked well.
Differential Revision: D4220565
Pulled By: mkonicek
fbshipit-source-id: e8a98542d3ff96d60ff6045b328f5b464f78ee74
Summary:
Follow on in https://github.com/facebook/react-native/pull/10864.
**Motivation**
ncuillery Is has a lot of experience with upgrading RN projects (see his [talk](http://www.slideshare.net/ncuillery/introducing-the-new-reactnative-upgrade)) and is rewriting 'react-native upgrade' to use git.
He tells me that we actually want git to merge changes in the .pbxproj file. In his words: "Making the project.pbxproj invisible for "git diff" means that react-native-git-upgrade will never be able to upgrade the project.pbxproj."
Note the git docs explicitly recommend not to use git to merge .pbxproj files: https://git-scm.com/book/en/v2/Customizing-Git-Git-Attributes#Binary-Files
ncuillery do we have an alternative? Some ideas:
1. Use a 3rd-party tool in 'react-native upgrade' to merge the .pbxproj file?
2. We could always re-generate and overwrite the .pbxproj file (never merge) and then run 'react-native link' to update native 3rd-party dependencies in the Xcode project?
3. Last resort: stay away
Closes https://github.com/facebook/react-native/pull/11047
Differential Revision: D4220521
fbshipit-source-id: 823c735856b519be114aa4349ca1392910f00445
Summary:
Just fixes a typo in an error message when running a simulator that XCode doesn't recognise.
Closes https://github.com/facebook/react-native/pull/11060
Differential Revision: D4220364
Pulled By: mkonicek
fbshipit-source-id: da7b9a529ad8cd77c6e144f4bbf3ea594a9efee4
Summary: Adds flow types for output functionality for easier maintenance and interop with new code
Reviewed By: matryoshcow
Differential Revision: D4211863
fbshipit-source-id: 591407d3a6d49536054ae94ba31125c18a1e1fa1
Summary:
Followup for CLI rewrite (https://github.com/facebook/react-native/commit/a477aec10d29b4651944cb4292daf06dfa953ea3). See the comment in the code for details.
**Test plan (required)**
- Published to Sinopia locally ([docs](https://github.com/facebook/react-native/tree/master/react-native-cli))
- Ran 'react-native init MyApp', the correct files were created (no more .npmignore, but have .gitignore):
$ cd MyApp
$ ls -a
. .flowconfig __tests__ ios
.. .gitattributes android node_modules
.babelrc .gitignore index.android.js package.json
.buckconfig .watchmanconfig index.ios.js yarn.lock
- Changed .flowconfig, ran 'react-native upgrade'. Saw a prompt "Do you want to overwrite .flowconfig", tried answering first 'n' and then 'y'. When answering 'y' the file was overwritten by the version from the template as expected.
Closes https://github.com/facebook/react-native/pull/11051
Differential Revision: D4214831
Pulled By: ericvicenti
fbshipit-source-id: 7c6aae4f97c7d45e7241bf017ed2f6527d5d29fe
Summary: Switch to native promises in the local cli
Reviewed By: davidaurelio
Differential Revision: D4213142
fbshipit-source-id: aff99f8bb3dc237cecc852cdb09dee9b49b05753
Summary: Correct header import paths, update podspec so we point at the copy in ReactCommon (and can eventually remove the copy under React)
Reviewed By: astreet
Differential Revision: D4204501
fbshipit-source-id: e979a010092f025b2cdc289e1e5f22fc7b65a8d1
Summary:
I had to re-do my CLI pull request internally using hg because shipit couldn't import binary files even after debugging with the OSS team. While using hg I messed up. This should fix it:
- Remove files added by mistake when using 'hg addremove'
- Add Xcode project that was ignored by hg (probably at fb we don't want people to check in Xcode projects since we use Buck)
**Test Plan**
Travis tests on this pull request.
Closes https://github.com/facebook/react-native/pull/11043
Differential Revision: D4212755
Pulled By: bestander
fbshipit-source-id: c762472ed31b9845425c1766510dce7761a35ae0
Summary: Uses `Logger` for the HMR Server output so that we get timestamps for free and the packager server output does not look as crappy.
Reviewed By: cpojer
Differential Revision: D4210827
fbshipit-source-id: e1ae64c359150b98c33e7b074f1111d37a2bc39b
Summary:
This is the manually imported version of https://github.com/facebook/react-native/pull/10786
This was mostly straigthforward by replacing the local-cli folder with the version I had in my local git checkout,
plus a few other files I listed with git diff --name-only.
Reviewed By: hramos
Differential Revision: D4201118
fbshipit-source-id: 4d0fb54b0edda9de1abba427958e420fd2ac105c
Summary:
This is the manually imported version of https://github.com/facebook/react-native/pull/10786
This was mostly straigthforward by replacing the local-cli folder with the version I had in my local git checkout,
plus a few other files I listed with git diff --name-only.
Reviewed By: hramos
Differential Revision: D4201118
fbshipit-source-id: 4d0fb54b0edda9de1abba427958e420fd2ac105c
Summary: This adds a new flag to the `unbundle` command: `--indexed-unbundle` allows to output the indexed file format even when building for android.
Reviewed By: cpojer
Differential Revision: D4189485
fbshipit-source-id: e56192456de764eb38c25b574ceaaf52eb8a6fca
Summary:
This is the next incremental step to rewrite node-haste. I apologize for the size of this diff but there is really no smaller way to do this. The current architecture passes a single file watcher instance into many classes that each subscribe to file changes. It's really hard to keep track of this. The new implementation reduces the listeners to two (will eventually be just one!) - one in DependencyGraph and one in it's parent's parent's parent (ugh! This doesn't make any sense). This should make it much more straightforward to understand what happens when a file changes.
I was able to remove a bunch of tests because jest's watcher takes care of things like ignore patterns. Some of the tests were specifically testing for whether the change events were invoked and they are now much more straightforward as well by manually invoking the `processFileChange` methods.
(Relanding a fixed version of D4161662)
Reviewed By: kentaromiura
Differential Revision: D4194378
fbshipit-source-id: 8c008247a911573f6b5f6b0b374d50d38f62a4f5
Summary:
Implements a multi-device proxy for the Chrome debugging protocol. Each device connects
to the proxy over a single websocket connection that is able to multiplex messages to multiple
Javascript VMs. An inspector instance running in Chrome can connect to a specific VM via this
proxy.
Reviewed By: davidaurelio
Differential Revision: D4088492
fbshipit-source-id: 3ee934e98604b5a378da732e687ca05fe3d23ce0
Summary:
Currently, to generate a `Release` build in `Android` it is required to get into the `android` directory and run the `react native bundle`with a lot of options and after that run the `gradle` to assemble or install the application with the build type `Release`.
This PR improves the process adding that feature to the `React Native CLI`.
To generate a release build is only required to use the parameter `--configuration` with the value `Release`.
**Examples**
To generate a release build:
```sh
react-native run-android --configuration release
```
To generate a release build for the product flavors staging:
```sh
react-native run-android --configuration release --flavor staging
```
To generate a debug build:
```sh
react-native run-android
```
To generate a debug build for the product flavors staging:
```sh
react-native run-android --flavor staging
```
This PR also removes the option `--install-debug` from the `react-native run-android` because that is always the default value,
Closes https://github.com/facebook/react-native/pull/10867
Differential Revision: D4167203
Pulled By: cpojer
fbshipit-source-id: c5ac07f81feeeea00ee0e8b059b46ef0d258a1a6
Summary:
This PR fixes#10784 by adding a `--help` and a `-h` option to `react-native-cli`.
**Test plan:**
Publish to sinopia and then outside of `react-native` project:
```
$ react-native --help #same goes for -h
Usage: react-native [command] [options]
Commands:
init <ProjectName> [options] generates a new project and installs its dependencies
Options:
-h, --help output usage information
-v, --version output the version number
```
```
$ react-native
You did not pass any commands, run `react-native --help` to see a list of all available commands.
```
**Notes:**
- There is no real consistency in the UX for `react-native-cli` and `local-cli` and even is no real consistency between the UI of `react-native [command] --help` and `react-native --help` in `local-cli` either. I tried to resemble the UX of `react-native --help` as close as possible since it's kind of the nearest neighbour.
- This *doesn't* add support for `react-native init --help` in `react-na
Closes https://github.com/facebook/react-native/pull/10828
Differential Revision: D4168266
Pulled By: hramos
fbshipit-source-id: 079917622bf5b22a3cd6414f13865c1b9c01da01
Summary:
With the current `run-ios` script it is not possible to create/run iOS release builds or any other kind of scheme configuration from the terminal (we need to use `Xcode`). The reason for this is that the `run-ios` script does not expose the scheme configuration option for the `xcodebuild` command. This PR exposes that property and allows the developers to directly create/run release builds from the terminal.
This PR also closes [this](https://productpains.com/post/react-native/create-ios-release-builds-from-terminal) request at `productpains`.
And answers to [this](http://stackoverflow.com/questions/40303229/run-a-react-native-ios-release-build-from-terminal) question at the `stackoverflow`.
**Test plan (required)**
To generate a release build just run:
``` sh
react-native run-ios --configuration Release
```
The output
``` sh
Found Xcode project App.xcodeproj
Launching iPhone 6 (iOS 9.3)...
Building using "xcodebuild -project App.xcodeproj -scheme App -destination id=B0738993-CE4A-4D
Closes https://github.com/facebook/react-native/pull/10637
Differential Revision: D4151793
Pulled By: cpojer
fbshipit-source-id: 5a0fcdd59589977f3e251ec9bb3ba85e8919cffc
Summary:
Fixes#10638.
Added NativeAnimation library to the starter project iOS generator. Passing `useNativeDriver: true` to `Animated` config will enable the app to tap into the native code for animations.
**Test plan**
Init a RN project and animate an element. Enable native driver as follows:
```
Animated.timing(
this.state.value,
{
toValue: 300, // some value
useNativeDriver: true
}
).start();
```
Earlier, this used to crash.
Closes https://github.com/facebook/react-native/pull/10783
Differential Revision: D4159386
Pulled By: mkonicek
fbshipit-source-id: 993481a31b4446eab24ef4ee35ae1941d7a7aae9
Summary:
Force npm for e2e tests.
Bonus: tracked down and removed a non-standard `.done()` call that was breaking e2e tests.
Reviewed By: bestander
Differential Revision: D4153514
fbshipit-source-id: 079939874ea75c7ea6e3e5376d37873c95fc74c1
Summary:
Link doesn't work on f8app,
as it is, android projects don't have to contain the matching string and then the linking would not work, I've switched it to the much simpler new-line.
If you can find a better common minimum string for settings.gradle please do.
Commit Msg:
Current string, `include ':app'\n`, is not a minimum common string.
Instead a simple `\n` will do.
Closes https://github.com/facebook/react-native/pull/10172
Differential Revision: D4150313
fbshipit-source-id: 34470e1fb67194e41354b6085fb3eb90ddaa7ff8
Summary: Use native Promises in React Native Packager. Remove all the non-standard `Promise.done()` calls throughout the codebase & replace `Promise.denodeify` with the stand-alone `denodeify` module.
Reviewed By: davidaurelio
Differential Revision: D4146965
fbshipit-source-id: 1730531c914863ac3c52626801d9f91c28eed717
Summary:
Check that 'react-native init' itself used yarn to install React Native.
When using an old global [email protected] (or older), we don't want to install React Native with npm, and React + Jest with yarn. Let's be safe and not mix yarn and npm in a single project.
**Test plan**
Publish the code in this PR to Sinopia, use that when creating a new project.
Using old CLI:
npm install -g [email protected]
react-native init AwesomeApp
The generated project doesn't contain `yarn.lock` (everything was installed with the npm client).
---
Using new CLI:
npm install -g [email protected]
react-native init AwesomeApp
The generated project contains `yarn.lock`, output shows that yarn is used to install React Native, React, Jest.
---
In both cases the project runs and Reload JS works:
Closes https://github.com/facebook/react-native/pull/10752
Differential Revision: D4131812
Pulled By: bestander
fbshipit-source-id: efaaf97a27005e2c2d10cae5d07afe108d5c0dee
Summary:
Ignore all keystore files as we do not want users to accidentally check in their keystore file.
Closes https://github.com/facebook/react-native/pull/10214
Differential Revision: D4118169
Pulled By: bestander
fbshipit-source-id: a81fc99afd1715d52dfdce8c47dfc10808470008
Summary:
Turns out I published 1.1.0 previously by accident and unpublished /ducks
Closes https://github.com/facebook/react-native/pull/10684
Differential Revision: D4111999
Pulled By: bestander
fbshipit-source-id: a85c8db6e7f48c9e96a649f017d82cbef44c73ae
Charles Dick
