Summary:
The breakage fixed by changeset [1] could have been identified earlier if we had typing on `attachHMRServer`, so I spent some time on that. This has revealed in turn a few functions across the codebase that were incorrectly typed, and that are now fixed.
[1] packager: attachHMRServer.js: fix callsite of Server#getModuleForPath()
Reviewed By: davidaurelio
Differential Revision: D4706241
fbshipit-source-id: fc4285245921ae45d5781a47d626fc0559dba998
Summary: In a previous changeset, Server#getModuleForPath() started returning `Promise<Module>` instead of `Module`, but the callsites in HMR haven't been updated, causing it to break. This would have been caught if `attachHMRServer.js` was using flow, that I'm considering doing in a following up diff. This would also have been caught if we had better integration testing of HMR. Good news however,it was caught by the OSS e2e test, that covers Hot Reloading.
Reviewed By: davidaurelio
Differential Revision: D4705937
fbshipit-source-id: fe787bc6ae50024759c7f7aeed747394fdce9aa1
Summary: The problem with `bundleOpts` is that it discards Flow typing, so it prevents reinforcing the integration of `Bundler` into `Server`. This changeset removes the `bundleOpts` to solve that issues. Instead, it makes the options explicit so that there is less uncertaintly. I love making options explicit, because they force callsites to take a consicious decision about what is really needed, making them more robust. They also expose oddities that probably needs refatoring, for example having a `resolutionRequest` in the bundle options does not seem correct, it should be an implementation details. Likewise, `onProgress` should probably be exposed differently, as it does not affect the content of the bundle itself.
Reviewed By: davidaurelio
Differential Revision: D4697729
fbshipit-source-id: d543870ba024e7588c10b101fa51429c77cc5ddc
Summary:
Minor code formatting.
Each time I run `react-native init` I must reindent this file.
Closes https://github.com/facebook/react-native/pull/12850
Differential Revision: D4691374
fbshipit-source-id: dc02b021e2f320f1046e4e6d024ba675a4213de8
Summary:
With the latest version of React Native I noted my setup with React Native Storybook stopped working because it stopped searching all the right project roots. I found that it had to do with the change here bce6ece5f6
**Test plan (required)**
Run the CLI with a project root other then the root directory and ensure that it displays both the specified project root and the actual root directory.
Closes https://github.com/facebook/react-native/pull/12659
Differential Revision: D4658137
Pulled By: ericvicenti
fbshipit-source-id: 97d3784348f92394df111f189c6b00dd0165b75e
Summary:
Motivation:
Few days ago gaearon [filed an issue](https://github.com/facebook/react-native/issues/12406) that examples in the react-native repo doesn't work after the [recent changes in local-cli](bce6ece5f6). This PR fixes reported bug.
**Test plan (required)**
- No UI changes
- [x] Run UIExplorer from XCode (no package.json in the folder) and check if packager/application runs correctly
cc davidaurelio satya164 grabbou
Closes https://github.com/facebook/react-native/pull/12435
Differential Revision: D4657370
Pulled By: ericvicenti
fbshipit-source-id: 72ee4b96cae37c7ed2794ed4490ce7b4fbbd66c3
Summary:
[Xcode](https://developer.apple.com/xcode/) is spelled with a lowercase `c`. 😄
**Test plan (required)**
ctrl-f project for `XCode`, case sensitive, find-and-replace with `Xcode`.
Make sure tests pass on both Travis and Circle CI.
Closes https://github.com/facebook/react-native/pull/12572
Differential Revision: D4622075
Pulled By: hramos
fbshipit-source-id: d64f0b10254cd624a71844ebaefa6fc29bc1ea57
Summary:
Similar to https://github.com/facebook/jest/pull/2877, this introduces an optional config `HasteImpl` of type `{getHasteName(filePath: string): (string|void)}` that returns the haste name for a module at filePath if it is a haste module or undefined otherwise.
This allows us to inject a custom implementation of haste's module id resolution rather than only relying on `providesModule` annotations
Reviewed By: davidaurelio
Differential Revision: D4589372
fbshipit-source-id: 4d1983dfbf09c9d67faf725e86ae86ab42433b7d
Summary:
This PR allows anyone to publish templates for React Native.
It's possible for people to publish modules for React Native, we should also support custom templates. A suggestion from a Cordova mantainer where they did the same thing suggests this is useful:
https://github.com/mkonicek/AppTemplateFeedback/issues/1
I published a sample template [react-native-template-demo](https://www.npmjs.com/package/react-native-template-demo).
(GitHub: https://github.com/mkonicek/react-native-template-demo)
With this PR anyone can then use that template:
`react-native init MyApp --template demo`
The convention is: if someone publishes an npm package called `react-native-template-foo`, people can use it by running `react-native init MyApp --template foo`.
Use a template called `react-native-template-demo` from npm:
`react-native init MyApp --template demo`
Use a local template:
`react-native init MyApp --template file:///path_to/react-native-template-dem
Closes https://github.com/facebook/react-native/pull/12548
Differential Revision: D4620567
Pulled By: mkonicek
fbshipit-source-id: bb40d457a7fec28edb577f08137e73241072de3a
Summary:
In the .flowconfig in the starter project, we're missing the correct suppression comments.
This should fix the flow issues in the e2e tests.
Closes https://github.com/facebook/react-native/pull/12533
Differential Revision: D4603657
Pulled By: ericvicenti
fbshipit-source-id: a07ec947d3ba746279c58e2d95c2293f54e06933
Summary:
**Test plan**
1. Add fonts using `react-native link` and a `"rnpm"` config in package.json
2. Manually delete one or more fonts from Xcode's Resources folder using Remove References option
3. Run `react-native link` again
With the patch in this PR, the plist will not accidentally get populated with duplicate entries.
Closes https://github.com/facebook/react-native/pull/12048
Differential Revision: D4560432
fbshipit-source-id: aba3733acfd5373f8d654406b06b8338b137bc07
Summary:
Currently it is not trivial for people to get started with React Native. `react-native init MyApp` just creates a simple app with a single screen. People have to spend time figuring out how to add more screens, or how to accomplish very basic tasks such as rendering a list of data or handling text input.
Let's add an option: `react-native init --template navigation` - this creates a "starter" app which can be easily tweaked into the actual app the person wants to build.
**Test plan (required)**
- Checked that 'react-native init MyApp' still works as before:
<img width="487" alt="screenshot 2017-02-02 16 56 28" src="https://cloud.githubusercontent.com/assets/346214/22559344/b2348ebe-e968-11e6-9032-d1c33216f490.png">
<img width="603" alt="screenshot 2017-02-02 16 58 04" src="https://cloud.githubusercontent.com/assets/346214/22559370/c96a2ca6-e968-11e6-91f7-7afb967920fc.png">
- Ran 'react-native init MyNavApp --template'. This prints the available templates:
```
$ react-native init MyNavApp
Closes https://github.com/facebook/react-native/pull/12170
Differential Revision: D4516241
Pulled By: mkonicek
fbshipit-source-id: 8ac081157919872e92947ed64ea64fb48078614d
Summary:
The iOS and Android native folders of a React Native app can be difficult to maintain. This introduces a new workflow for creating and maintaining the native code of your app.
Now it will be possible to:
1. Remove the native iOS or Android folders
2. Create an `app.json` for your app, with at least a `name` and `displayName`
3. Run `react-native eject`, and the native code for your app will be generated
Then, as usual, you can run `react-native run-ios` and `react-native run-android`, to build and launch your app
For apps that don't have any native code, it will be possible to ignore the `ios` and `android` folders from version control.
Eject step tested in RN app by deleting native folders.
mkonicek, what is the best way to test `react-native init`?
As follow-up items, we can enable the following:
- Configuring app icon and launch screen from the `app.json`
- Automatically run `react-native link` for native libraries
- A
Closes https://github.com/facebook/react-native/pull/12162
Differential Revision: D4509138
Pulled By: ericvicenti
fbshipit-source-id: 0ee213e68f0a3d44bfce337e3ec43e5024bacc66
Summary:
Ignores `bundle.js` that is a webpack bundle and got most likely accidentally released. Already cherry-picked to 0.42
Fixes#12183
Closes https://github.com/facebook/react-native/pull/12185
Differential Revision: D4507535
Pulled By: mkonicek
fbshipit-source-id: 2ab404534b345cf531f408b654c34a30abd01458
Summary:
This moves the `src` directory one level up and removes the `react-packager` folder. Personally, I always disliked this indirection. I'm reorganizing some things in RNP, so this seems to make sense.
Not sure if I forgot to update any paths. Can anyone advice if there are more places that need change?
Reviewed By: jeanlauliac
Differential Revision: D4487867
fbshipit-source-id: d63f9c79d6238300df9632d2e6a4e6a4196d5ccb
Summary:
I prefer a darker environment when coding, and having the Chrome window be dark except the part that I cannot hide, is making my eyes hurt. This is for the people that prefer the darker color scheme when developing.
Closes https://github.com/facebook/react-native/pull/11878
Differential Revision: D4494415
Pulled By: mkonicek
fbshipit-source-id: 423473ec073e6ddd0d14322c22ee37abed1c55bc
Summary:
Hi RN team! Thanks for all that you do. 🎉
**Motivation:**
I noticed in the [Buck docs](https://buckbuild.com/article/exopackage.html) (scroll down to Step 2) that it expects third party JARs to live in version control. Currently, the HelloWorld template ignores these dependencies from version control, which is a bit confusing.
Closes https://github.com/facebook/react-native/pull/11738
Differential Revision: D4494423
Pulled By: mkonicek
fbshipit-source-id: 37b946ad9c30af2b47b409bae6830bba5917491a
Summary:
Basic template using 'react-navigation' to make it easy to get started.
Not duplicating all the files in `android` and `ios` folders. These will be taken from the `HelloWorld` template. Let's not duplicate all of these files (it's a lot and they are large, especially the Xcode projects).
**Test plan (required)**
The app works locally. This PR is just a preparation for a next PR that will add support for 'react-native init --template Navigation'. Will have a proper test plan there.
Closes https://github.com/facebook/react-native/pull/12153
Differential Revision: D4494776
Pulled By: mkonicek
fbshipit-source-id: b43eafd7a1424477f9493a3eb4083ba4dd3d3846
Summary:
Currently React Native's local cli is a bit behind in its android gradle plugin version. This PR is an attempt to update the local cli, to allow for better support moving forward.
* Updates the gradle plugin version to 2.2.3
* Updates the gradle wrapper to 2.14.1
* Uses the `all` for the project wrapper to include sources for API completion
**Test plan (required)**
* Perform all required steps here: https://github.com/facebook/react-native/tree/master/react-native-cli
* Run the local npm tests and e2e tests (no longer available)
* Test the local cli by using Sinopia
Make sure tests pass on both Travis and Circle CI.
TO NOTE: In a previous issue (https://github.com/facebook/react-native/issues/11500) I was able to update to 2.2.3 comfortably, however there may be other issue I am not aware of. This PR is intended to start discussion on what it will take to update.
Closes https://github.com/facebook/react-native/pull/11930
Differential Revision: D4489926
Pulled By: mkonicek
fbshipit-source-id: 35ff5ac6b1b8893854538d6b9fe2c2e042ecca9f
Summary:
Largely typing fixes to deal with the glut of new `FlowFixMe` suppressions introduced with flow 0.38 in a4bfac907e
Tested with flow itself. CC gabelevi
Closes https://github.com/facebook/react-native/pull/11985
Differential Revision: D4452045
Pulled By: ericvicenti
fbshipit-source-id: acc46c4c406ae706a679e396be1d40ae2f4ce5a1
Summary:
Support symlinks under `node_modules` for all local-cli commands. PR https://github.com/facebook/react-native/pull/9009 only adds symlink support to the packager.
But other cli commands like `react-native bundle` creates its own instance of packager that doesn't have symlinks as part of its project roots, which results in the bundler breaking since it cannot find modules that you have symlinked.
This change ensures all `local-cli` commands add symlinks to its project roots.
Test plan (required)
1. Create a symlink in node_modules (for instance use npm/yarn link)
2. Run `react-native bundle`.
Closes https://github.com/facebook/react-native/pull/11810
Differential Revision: D4487741
fbshipit-source-id: 87fe44194134d086dca4eaca99ee5742d6eadb69
Summary:
When installing template by `react-native init AwesomeProject` and adding checkstyle to the Gradle setup, it will complain about unused imports
Closes https://github.com/facebook/react-native/pull/12076
Differential Revision: D4470930
fbshipit-source-id: 50a105886607fd1d3a458453fa1a844e9746dafa
Summary:
Also fix lint errors about Buffer being undefined by adding env: node to the eslint config for local-cli.
Tested on windows 10.
Closes https://github.com/facebook/react-native/pull/11959
Differential Revision: D4438903
Pulled By: hramos
fbshipit-source-id: 28d5edd662dd1e63dedf1274ff0a21af4df84f5e
Summary:
Fixes https://github.com/facebook/react-native/issues/11861 - the release config is currently broken for projects created by `react-native init` in `master`, 0.40 and 0.39.
I'm still investigating when and how this got broken but this seems to be a clean fix. I've added `-ObjC` as well to match the main target but I'm not sure yet whether that's necessary.
To test:
```
react-native init fooproject --version react-native@rh389/react-native#missinglinkerflags
```
Open in XCode, Edit scheme (⌘<), Change `Build Configuration` to `Release`, build.
Update: The `-lc++` flag became necessary when 33deaad196 landed because of the libstdc++ dependencies of `RCTLog`. Still not sure about `-ObjC`. javache ?
Closes https://github.com/facebook/react-native/pull/11889
Differential Revision: D4421685
Pulled By: javache
fbshipit-source-id: 954edaef773f8cef7b7ad671fa4d1f2bfc2f20f2
Summary:
A bit late to the party, but upgraded, tests replaced, all green.
Also updated `pbxproj` so that we are testing against React 0.40 init result, not against something old.
To cherry-pick and land once ships.
Closes https://github.com/facebook/react-native/pull/11868
Differential Revision: D4411362
fbshipit-source-id: c485fd76114979d34a7e288bb70e1ecb9b3baf76
Summary:
Introduces a new mechanism to build source maps that allows us to use real mapping segments instead of just mapping line-by-line.
This mechanism is only used when building development bundles to improve the debugging experience in Chrome.
The new mechanism takes advantage of a new feature in babel-generator that exposes raw mapping objects. These raw mapping objects are converted to arrays with 2, 4, or 5 for the most compact representation possible.
We no longer generate a source map for the bundle that maps each line to itself in conjunction with configuring babel generator to retain lines.
Instead, we create a source map with a large mappings object produced from the mappings of each individual file in conjunction with a “carry over” – the number of preceding lines in the bundle.
The implementation makes a couple of assumptions that hold true for babel transform results, e.g. mappings being in the order of the generated code, and that a block of mappings always belongs to the same source file. In addition, the implementation avoids allocation of objects and strings at all costs. All calculations are purely numeric, and base64 vlq produces numeric ascii character codes. These are written to a preallocated buffer objects, which is turned to a string only at the end of the building process. This implementation is ~5x faster than using the source-map library.
In addition to providing development source maps that work better, we can now also produce individual high-quality source maps for production builds and combine them to an “index source map”. This approach is unfeasable for development source maps, because index source map consistently crash Chrome.
Better production source maps are useful to get precise information about source location and symbol names when symbolicating stack traces from crashes in production.
Reviewed By: jeanlauliac
Differential Revision: D4382290
fbshipit-source-id: 365a176fa142729d0a4cef43edeb81084361e54d
Summary:
We don't need to look for `thisDependency` as we already have it. Small improvement as I am working on other fixes.
Closes https://github.com/facebook/react-native/pull/11867
Differential Revision: D4411177
fbshipit-source-id: 1413eb5457cb4d7916ead90f438ffe158f644cad
Summary:
This is step one on merging the `rnpm` config with the `cli config`. The plan is to remove two sources of truth (rnpm package.json config and rn-cli Javascript config)
Rationale:
As of now, we have `rnpm` config, that used to live in the `local-cli/core/config/index.js` and the `rn-cli` config, living in `default.config.js` and `utils/Config.js`.
This PR moves all the things into one file, called `local-cli/core', simplifies things, enhances types (Config now has better types, added missing properties and fixed descriptions).
One notable addition is that users can now opt-in to override the commands that are loaded at the package level. Previously it was only possible to add a command by writing a plugin. Now, you can just tweak the `rn-cli.config.js`.
This is one of the several improvements I have on my roadmap, with better documentation for the CLI as well.
Closes https://github.com/facebook/react-native/pull/11564
Differential Revision: D4360095
fbshipit-source-id: feaec7c88df63e51cef1f9620c7eedeb738d3d00
Summary:
Currently, while running `react-native run-android` command, React Native's packager is launched, and there is not any way to disable the current behaviour. This is handled somehow on iOS by adding an environment variable `RCT_NO_LAUNCH_PACKAGER` (see #6180).
This is a cross-platform solution that adds the `--no-packager` option both to `run-ios` and `run-android`, which prevents the packager from being launched.
This was tested by building with and without the option, on both environments (Android and iOS) using the device and simulator, working as expected.
Closes https://github.com/facebook/react-native/pull/11735
Differential Revision: D4392170
Pulled By: ericvicenti
fbshipit-source-id: 1c31f109f18715b84cd5ab1b6d5fd758cd0a6efb
Summary:
As mkonicek suggested in [#9568](https://github.com/facebook/react-native/pull/9568#issuecomment-267600043) I did some cleanup
**Test plan (required)**
Only one functional change:
> Run `react-native run-android --deviceId`
Before it was beginning to build the app and then failing because of the missing device "true" :-)
Now it's showing a message and stopping the build:
```
❯ react-native run-android --deviceId
Starting JS server...
Parameter missing (device id)
```
Closes https://github.com/facebook/react-native/pull/11703
Differential Revision: D4376615
Pulled By: ericvicenti
fbshipit-source-id: 3c6e0f12220ab22539c7bc3d390367e02c96728a
Summary:
**Motivation**
New iOS project generation with react-native-cli should allow developers to build for Apple TV as well as iPhone/iPad.
**Test plan**
Added to `scripts/run-ci-e2e-tests.js` and `.travis.yml` to have the new tvOS target automatically built and tested in Travis CI.
Closes https://github.com/facebook/react-native/pull/11591
Differential Revision: D4375593
Pulled By: mkonicek
fbshipit-source-id: 4e241caa400a88e6b2f91416fa26b48ae01cb7b6
Summary:
Fixes#11605
HelloWorld refers to CSSLayout even thought master has moved on and the library is now called Yoga.
Closes https://github.com/facebook/react-native/pull/11606
Differential Revision: D4365469
fbshipit-source-id: e0eaac400449f0ba767bf98f3bd8e8185fb6fd12
Summary:
Running `master` (at 260d68bf8b) I noticed `react-native link` fails when there is no windows project due to a bug in the code that fetches windows project configs (introduced 445182c707).
There's a guard to return early if `csSolution` (the relative path of the windows solution) is null but it needs to be a line earlier, because `path.join` errors when passed a non-string.
Tested locally on a non-windows project, `react-native link` errored previously and now succeeds.
Closes https://github.com/facebook/react-native/pull/11590
Differential Revision: D4362419
fbshipit-source-id: b3b9f6784d8b1d1a7c53abe0ee421b1dc6048571
Summary:
Due to react-native-cli use yarn if yarn is available, we need to add yarn-error.log to .gitignore.
Closes https://github.com/facebook/react-native/pull/11583
Differential Revision: D4359507
fbshipit-source-id: 0c7582215a31e0d03dced138c8275225910713ee
Summary:
At the moment the run-android command from the react-native cli does run all available devices at once. However it would be extreme useful to have the option to choose only one specific device/simulator.
Therefore i've created a new flag for the command 'run-android': --deviceIdFromList 'deviceIdFromList' in order
to install and launch apps on a specific device/simulator from the command line.
'deviceIdFromList' is the id listed on the output of the command 'adb devices'.
I've tested my code with the following commands:
react-native run-android --deviceIdFromList "Not existing id"
react-native run-android --deviceIdFromList
react-native run-android --deviceIdFromList "id of a simulator"
react-native run-android --deviceIdFromList "id of a device"
Output:
![not-existing-device](https://cloud.githubusercontent.com/assets/9102810/17931086/d843abc8-6a09-11e6-995d-8c737dd5ed5c.png)
![empty-flag](https://cloud.githubusercontent.com/assets/9102810/17931087/d8443930-6a09-11e6-94f3-d
Closes https://github.com/facebook/react-native/pull/9568
Differential Revision: D4335133
Pulled By: mkonicek
fbshipit-source-id: a827628316be1b5751225851323b1131f451574c
Summary: This was buggy and didn't print the folder we need to cd into.
Reviewed By: mkonicek
Differential Revision:
D4313396
Ninja: OSS only
fbshipit-source-id: 0e15baf818065b63e939def60a1366e2251aac7d
Summary:
Seeing as [Windows is a supported platform](72157cf991/packager/defaults.js (L22)) until platforms can better manager their own CLI and packager needs.
Linking 3rd party libraries should be supported first, because then I'd like to do a follow up PR with grabbou to identify how we can effectively move RNPM functionality out of react-native core and eventually housed in each external platform's repo. The goal would be working with cpojer and hopefully andrewimm to help keep external platform needs in their respective repos, for rnpm/packager _et al._ Seeing as this is a major discussion point, I've made this PR first. Making small steps towards this goal, seems to be the approved methodology from all.
Additionally, I have a merged PR that makes an excellent place for documenting the CLI when it advances, as preparatio
Closes https://github.com/facebook/react-native/pull/11282
Differential Revision: D4311391
fbshipit-source-id: be9a836344be4aed6c4732b0ce4947c2a16b6dad
Summary:
This is a simple one line change. When a red box is launching the editor, if `launchEditor.js` is aware of your editor it can also add a line number to open the file at. So if the stacktrace shows an error on like 56 in `ako.js` then it'll try`wstorm /Users/somelady/src/project/ako.js:56` instead of `wstorm /Users/somelady/src/project/ako.js`.
This adds PyCharm's command line launcher, which is named `charm`. There is existing logic to handle other JetBrains editors, so I just did a simple one line addition.
**Test plan (required)**
* Install PyCharm (if needed)
* Set environment variable `REACT_EDITOR` to `charm`
* Open PyCharm
* Add/replace the current `charm` command via `Tools -> Create Command-line launcher...` in PyCharm.
* Run a React Native project with an error in the source code.
* In the generated red box, click on one of the entries in the stack trace
* File should open in PyCharm at the correct line number.
Closes https://github.com/facebook/react-native/pull/11275
Differential Revision: D4295724
Pulled By: javache
fbshipit-source-id: 29dec525f76c2f0a3ee203cac67408eecc8ac6b6
Summary:
Xcode really sucks, per some discussion on e1577df1fd and https://developer.apple.com/library/content/technotes/tn2215/_index.html, if you use the headers phase, and mark headers in your static library as public, they will actually end up in the final package that's built and you can't submit to the app store! This changes our xcode setup to use a copy files phase instead.
I've also changed the header include path to be $(BUILT_PRODUCTS_DIR)/include, which is added to the include path by Xcode by default, so 3rd party libraries should not be impacted by these changes anymore.
Reviewed By: mkonicek
Differential Revision: D4291607
fbshipit-source-id: 969b9ebcbeb8161f85427f8c429e198d9d0fae30
Summary:
I missed this while doing the Yeoman wipeout.
Currently we just print:
Installing React...
Installing Jest...
This diff makes it print the output of those commands.
**Test Plan**
Published react-native to Sinopia, ran `react-native init MyApp`, saw the output:
Installing Jest...
⸨░░░░░░░░░░░░░░░⸩ ⠸ normalizeTree: ...
Reviewed By: bestander
Differential Revision: D4286640
fbshipit-source-id: e554f03a4729c2de85eba527f10f4b727de722e4
Summary:
This module is not actually used inside of React Native. Projects that use this,
can now depend on https://www.npmjs.com/package/signedsource
Reviewed By: yungsters
Differential Revision: D4272511
fbshipit-source-id: 93eb74aa4ccfa8ef8743de2cfa92b5403de91e0a
Summary:
**Motivation**
This morning I was trying to test on iPhone 7 with iOS 10 so I booted that device and ran "react-native run-ios" expecting it to notice I had a simulator running and install my app to it. Instead it switched my device to the iPhone 6s iOS 9.2. After digging it was found that run-ios did not handle multiple versions of iOS being installed very well when it came to checking for the booted device. This PR resolves that.
**Test plan (required)**
Tests were added for the situation of multiple iOS versions being installed and a slight change to the code was completed to make the new tests pass and continue to keep the old tests passing.
Closes https://github.com/facebook/react-native/pull/10558
Differential Revision: D4163616
Pulled By: hramos
fbshipit-source-id: 26b44fb73ef402ce252e7a754036279e15359170
Summary:
I was running RN 0.31 on ArchLinux (kernel 4.7), and "react-native start"
was refusing to run on the default (and sometimes required, as I have
noticed) port. I tried executing the suggested lsof command, but that did not
work. Somewhere I found the lsof command I include in this commit, and that
worked (it was a node.js process). So I'm including it, since I found it
helpful.
Closes https://github.com/facebook/react-native/pull/9402
Reviewed By: lacker
Differential Revision: D4144400
Pulled By: hramos
fbshipit-source-id: 6203549455555efc59b7bab0a3ec23957d80b956