Summary: It's now unnecessary to declare which JS modules you want to expose on your package. To upgrade, remove all overrides of `createJSModules` and keeping calling your JS modules as before.
Reviewed By: AaaChiuuu
Differential Revision: D5229259
fbshipit-source-id: 1160826c951433722f1fe0421c1200883ba1a348
Summary:
This diff cleans up some cruft and adds some features:
* It removes the usage of an env variable to control workers.
* It removes the lazy and handwavy calculation on how many workers to use for jest-haste-map. Jest itself uses the maximum amount of workers available and it has never been reported as an issue – especially since it is a one-time startup cost of about 3 seconds on a cold cache only.
* It adds a `--max-workers` flag to replace the env variable. This one is able to control both the number of workers for `jest-haste-map` as well as the transformers.
* It makes the transformers run in the parent process if 1 or fewer workers are are specified. This should help with debugging.
Once you approve this diff, I will publish a new version of metro to npm and update the version used in RN and remove the use of the env variable altogether: https://our.intern.facebook.com/intern/biggrep/?corpus=xplat&filename=&case=false&view=default&extre=&s=REACT_NATIVE_MAX_WORKERS&engine=apr_strmatch&context=false&filter[uninteresting]=false&filter[intern]=false&filter[test]=false&grep_regex=
Note: the process of adding a CLI option is really broken. Commander also has a weird API. We should consider building a better public API for Metro and then consider how to build a new CLI on top of it and simplify our internal integration. I really don't like how Metro is integrated across pieces of the RN cli in ways that is hard to manage. But that is a larger task for another time :)
Reviewed By: jeanlauliac
Differential Revision: D5217726
fbshipit-source-id: 74efddbb87755a9e744c816fbc62efa21f6a79bf
Summary:
In <= 0.44, the default implementation of getProjectRoots() came from `local-cli/core/default.config.js`. With changes happening in the CLI and the packager over the course of the last two months, various pieces of this logic (specifically `local-cli/utils/Config.js`) were rewritten, and though default.config.js was still being imported and used in `local-cli/core/index.js`, the default `getProjectRoots()` was being overriden by the defaults specified in `local-cli/utils/Config.js`.
This PR moves the logic from default.config.js into Config.js and index.js, as appropriate. Specifically:
- The `getProjectCommands()`, `getProjectConfig()`, and `getDependencyConfig()` methods, which have traditionally not been part of the rn-cli.config.js spec, are now defined in `local-cli/core/index.js`.
- The `getProjectRoots()` method, which contained logic for properly resolving the _actual_ project root as well as resolving symlinks within that root, has been moved to `local-cli/utils/Config.js`, to match the fact that other default rn-cli.config.js definitions live there.
Closes https://github.com/facebook/react-native/pull/14412
Differential Revision: D5216887
Pulled By: hramos
fbshipit-source-id: 7a3840ecf0ad8ea3f6d7bbd3d54e4f02950c6a32
Summary: This folder is not necessary any longer. All the code now lives in https://github.com/facebook/metro-bundler
Reviewed By: davidaurelio, jeanlauliac
Differential Revision: D5199196
fbshipit-source-id: 35bf0f10a9163f53426db9a76f8f853dceb69167
Summary:
`react-native link` often fails due to the wrong manifest being used when you use a debug manifest. `findManifest` returns `debug/AndroidManifest.xml` instead of `main/AndroidManifest.xml`. And the debug manifest usually does not have the package name defined so `projectConfigAndroid` throws a cryptic "Cannot read property 'replace' of undefined" error.
This fixes the issue by throwing a more user friendly error and providing a `manifestPath` userConfig.
This is mostly based on comments to #10050.
Closes https://github.com/facebook/react-native/pull/13373
Differential Revision: D4945690
Pulled By: shergin
fbshipit-source-id: b177f916fd4799c873d2515c18cbb87bef3203f0
Summary:
The packager dependencies CLI command always operates on --dev=true today. This means any tooling that needs to get the production dependencies (--dev=false) will always get the dev-mode list instead. For instance:
```
if (__DEV__) {
require('Foobar');
}
```
Previously, `Foobar.js` will always be listed in the CLI output. With this change, setting `--dev false` option will correctly skip `Foobar.js` in the output.
Reviewed By: cpojer
Differential Revision: D5163184
fbshipit-source-id: 203221ee5d6ecb7df575442f12f6c4c489bfbd46
Summary:
Adding shebang to local-cli's setup_env script.
Depending how your *nix environment is setup, running `react-native bundle` will throw this error:
```
Error: spawnSync /opt/build/in/node_modules/react-native/local-cli/setup_env.sh Unknown system error -8
at exports._errnoException (util.js:1022:11)
at spawnSync (child_process.js:461:20)
at Object.execFileSync (child_process.js:498:13)
at repl:1:14
at sigintHandlersWrap (vm.js:22:35)
at sigintHandlersWrap (vm.js:96:12)
at ContextifyScript.Script.runInThisContext (vm.js:21:12)
at REPLServer.defaultEval (repl.js:346:29)
at bound (domain.js:280:14)
at REPLServer.runBound [as eval] (domain.js:293:12)
```
In my case I was running react-native on docker (using alpine-node:6 as base image).
Closes https://github.com/facebook/react-native/pull/12173
Differential Revision: D5154069
Pulled By: shergin
fbshipit-source-id: acf2a21499b4a57310afd06b57386e7900662b7d
Summary:
- new-library was copying file inside the <project_root>/node_modules/react-native/Libraries instead of <project_root>/Libraries. This was due to the path.resolve that was being passed 2 full paths instead of a base path + relative path segment.
---
Before:
```js
console.log(libraryDest, dest, path.resolve(libraryDest, dest);
// <base-path>/Libraries/TestLib
// <base-path>/node_modules/react-native/Libraries/TestLib/package.json
// <base-path>/node_modules/react-native/Libraries/TestLib/package.json
```
After:
```js
console.log(libraryDest, dest, path.resolve(libraryDest, dest);
// <base-path>/Libraries/TestLib
// ../TestLib/package.json
// <base-path>/Libraries/TestLib/package.json
```
Closes https://github.com/facebook/react-native/pull/13748
Differential Revision: D5043652
Pulled By: shergin
fbshipit-source-id: febee13781fc7075276daa67f9a78cc73dfd4b73
Summary:
Maintainers - hoping theres a chance this could be cherry-picked into 0.44-stable as it's a very minor change to the local-cli.
Our iOS app has 3 different configurations, each with a separate Product Name. When building for debugging on the simulator with the `react-native run-ios` command, the build would complete successfully but would error in trying to install to the simulator. I tracked the error down to the regex I've updated in this PR which was looking for the full product name in the build output, but the regex there wasn't using the multiline flag so it never matched.
I've tested this locally with our app and it now works as expected. If I specify a different configuration with `react-native run-ios --configuration Beta` (for example), it properly detects the Product Name for the configuration and installs correctly as well.
Closes https://github.com/facebook/react-native/pull/14071
Differential Revision: D5141414
Pulled By: shergin
fbshipit-source-id: 23bceb8a9650cc0cf2a83ea92ad417049240da4e
Summary:
This changeset moves the creation of the transform cache at the top-level of the bundler so that:
* we can use alternative folders, such as the project path itself, that I think will be more robust especially for OSS;
* we can disable the cache completely, that is useful in some cases (for example, the script that fills the global cache).
The reasons I believe a local project path is more robust are:
* there are less likely conflicts between different users and different projects on a single machine;
* the cache is de facto cleaned up if you clone a fresh copy of a project, something I think is desirable;
* some people have been reporting that `tmpDir` just returns nothing;
* finally, it prevents another user from writing malicious transformed code in the cache into the shared temp dir—only people with write access to the project have write access to the cache, that is consistent.
Reviewed By: davidaurelio
Differential Revision: D5113121
fbshipit-source-id: 74392733a0be306a7119516d7905fc43cd8c778e
Summary:
* Internally, we already set up babel before calling into metro-bundler.
* Externally, I moved the setup calls to outside the packager/ folder.
If somebody has a custom integration with RN, they would need to setup babel themselves up until we make the open source split. By the time this is released in open source, an npm version of metro-bundler will be available for use.
Next step: also do this for the worker and remove setupBabel from the metro repo.
Reviewed By: davidaurelio
Differential Revision: D5121429
fbshipit-source-id: e77c6ccc23bef1d13fd74c4727be2d7e09d2d0ca
Summary: Adds support for “RAM bundle groups” (common section for module groups) to the new Buck integration
Reviewed By: jeanlauliac
Differential Revision: D5112065
fbshipit-source-id: 038c06b8f4133c7fcd39aba8bb04a5ef42594f3e
Summary: in order to prepare open sourcing React Native Packager, we have to move scripts specific to React Native to a directory that will continue to exist.
Reviewed By: javache
Differential Revision: D5112193
fbshipit-source-id: eac77d0d981aecef7ee52365a6856340420a5638
Summary:
Make all properties of `ModuleTraansportLike` covariant to enforce read-only behavior at all sites using it.
The type only exists for compatibility reasons between old and new output functionality, and covariant properties give us stronger guarantees.
Reviewed By: jeanlauliac
Differential Revision: D5111667
fbshipit-source-id: 674658b07eb3a229cbc4344cb636e4a9ea4126d1
Summary: Adds functionality to assemble an indexed source map to the new Buck integration. This implementation supports startup section optimisations. Hooking it up, and grouping optimisations will be in follow-ups.
Reviewed By: jeanlauliac
Differential Revision: D5106985
fbshipit-source-id: cc4c6ac8cfe4e718fc8bb2a8a93cb88914c92e0b
Summary: For the Buck integration (work-in-progress), we want to add the ability to do some custom preprocessing similar to the packager server. The signature is different so I prefer to have a separate function for that. Also we don't need the transform options right now, I suggest we don't add them for now and add them later if necessary.
Reviewed By: davidaurelio
Differential Revision: D5094632
fbshipit-source-id: 1775ddef90b331deabc5be3e57a67436bce06c82
Summary: Adds flow to `local-cli/bundle/output/meta.js`, and makes some changes to avoid errors.
Reviewed By: cpojer
Differential Revision: D5077563
fbshipit-source-id: bafb9e6705319f6f2e8ae1c820667ad343191b3c
Summary:
After examining how React Native sets up `process.env.NODE_ENV` using `global.__DEV__` from `prelude_dev.js` or `prelude.js` by treating them like polyfills I decided to use the same approach for environment variables. I setup my own rn-project.config.js file like so:
```
const blacklist = require('react-native/packager/blacklist');
const pathJoin = require('path').join;
module.exports = {
getBlacklistRE: function() {
return blacklist([/build\/.*/, /app\/assets\/webpack.*/]);
},
polyfillModuleNames: [pathJoin(__dirname, 'globals.js')]
};
```
I ran the packaging server using:
`react-native start --config=config/react-native/rn-project.config.js --reset-cache`
I expected my polyfillModuleNames to be passed into the Packager properly and be handled the same way the built-in polyfills worked. Unfortunately I noticed the Packager wasn't actually getting `opt.polyfillModuleNames`. Digging into the code a bit, it seems the local-cli wasn't passing the polyfillModuleNames from the config.
There are no specs for runServer.js but this change can be tested by using a config that contains polyfillModuleNames. Sample config and run command provided above simple `global.js` provided below:
```
global.process = global.process ? global.process : {};
global.process.env = global.process.env ? global.process.env : {};
global.process.env['PROJECT_ENV'] = 'staging';
```
Closes https://github.com/facebook/react-native/pull/13725
Differential Revision: D5077615
Pulled By: jeanlauliac
fbshipit-source-id: f66a8a8bda2702cd9a4e5b92f5335f43ab2f9089
Summary: I'd like to start typing the front-end so that it's easier to track adding new options, etc.
Reviewed By: davidaurelio
Differential Revision: D5069868
fbshipit-source-id: 9a18dca52efd486ca18f17d0ec434a5ec1c1649c
Summary: This makes it easier to verify correctness when adding new config/args.
Reviewed By: davidaurelio
Differential Revision: D5069537
fbshipit-source-id: 4d8058851900b23163d0f2744e91dd14dfcdd461
Summary: `transformModulePath` used to be an optional string, because `ConfigT` allowed for an optional `getTransformModulePath` method. Effectively, we required it to be present. This builds on top of the cleanups around `ConfigT` and gets rid of the flow error suppressions
Reviewed By: jeanlauliac
Differential Revision: D5037466
fbshipit-source-id: bc5c9cbc566e7aa74e7f6397e69fa87cdac7bc00
Summary: I've been confused for a long time by this, and I think it's better late than never. I propose we rename that file to make it more explicit where that class lives, and so that it's consistent with the test file, name `DependencyGraph-test.js`
Reviewed By: davidaurelio
Differential Revision: D5020556
fbshipit-source-id: d54a501c3995f3fea16a5bfc6ca72993f73c4873
Summary:
Existing instructions are a bit misleading, as Chrome extension is not supposed to work, but there is still a supported way to run them.
Closes https://github.com/facebook/react-native/pull/13707
Differential Revision: D5010169
Pulled By: gaearon
fbshipit-source-id: f9558c9ccb04196854b2eef6ff40a998350b65db
Summary: Enforces a `'default'` property to be present on the transform variant mapping. This will allow us to simplify transforms of assets and json to only provide one variant for the new Buck build system.
Reviewed By: jeanlauliac
Differential Revision: D5002052
fbshipit-source-id: 2a7240c1b2450f62de686c46ab2c2e5a75dea399
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: deduplicates / unifies types for source maps across the code base
Reviewed By: jeanlauliac
Differential Revision: D4955924
fbshipit-source-id: 25cb71031dce835dd7d2bc1c27d6b20050906e81
Summary:
The cli arg `--scheme` allows you to override the inferred scheme.
The runOnDevice command takes this override into account, but run-ios
doesn't. This commit fixes this discrepancy.
Thanks for submitting a PR! Please read these instructions carefully:
- [x] Explain the **motivation** for making this change.
- [x] Provide a **test plan** demonstrating that the code is solid.
- [x] Match the **code formatting** of the rest of the codebase.
- [x] Target the `master` branch, NOT a "stable" branch.
Currently if a custom scheme is specified, `run-ios` will fail with the following message
```
Error: Command failed: /usr/libexec/PlistBuddy -c Print:CFBundleIdentifier build/Build/Products/Debug-iphonesimulator/AwesomeProject.app/Info.plist
Print: Entry, ":CFBundleIdentifier", Does Not Exist
```
This PR fixes this.
Tested manually from CLI.
Closes https://github.com/facebook/react-native/pull/13548
Differential Revision: D4914531
Pulled By: javache
fbshipit-source-id: 071710947e90e6194e0229751e33068565e010b2
Summary:
I have been working on integrating React Native into an existing app and realised that the source folder for android code is currently hardcoded as `app`. Being a legacy codebase we can't really change that. So I wanted to be able to customise this folder name so that I can integrate RN seamlessly and start it from the CLI without having to run it from Android Studio.
- Create a barebones RN app
- `react-native run-android` works successfully
- Refactor the name of the app folder inside the android directory to `TestFolderName` using Android Studio
- `react-native run-android` now fails
- Changing this command to `react-native run-android --appFolder=TestFolderName` works successfully
Closes https://github.com/facebook/react-native/pull/13273
Differential Revision: D4833396
Pulled By: ericvicenti
fbshipit-source-id: 4c62cee6aaa2cc78eede5c7756459430022fffde
Summary:
This PR adds support for configurable devEnabled option when building an android app. This is currently hardcoded.
The reason for making this configurable is this: I have an app that uses code-push and 3 buildConfigs. I want to have a debugging version which has `devEnabled = true`, then a staging version which has `devEnabled = false` (this version of the app is used internally for testing and should behave just like a release version of the app, and when the tests succeed the changes are promoted into the release version to the users out there, using code-push). The last version is a standard release version with `devEnabled = false`.
Currently, `devEnabled` is hardwired like this: `!targetName.toLowerCase().contains("release")` so by default my `staging` buildConfig will have `devEnabled = true` but I'd like it to be false.
With this PR it'd be possible to configure this as follows, while not breaking the current behavior.
`'devDisabledIn${productFlavor}${buildType}'`
`'devDisabledIn${buildType
Closes https://github.com/facebook/react-native/pull/11438
Differential Revision: D4630513
Pulled By: hramos
fbshipit-source-id: b6817cf4c144fc948f76785e9cb5f93a13a6a6a2
Summary:
Motivation
Currently react-native run-android instals and starts your app, but if you have more than one variant, it doesn't know which one to start. This allows developers to pass in the suffix specified in build.gradle, so that the correct app is started.
Test Plan
verify that `react-native run-android` runs properly
verify that `react-native run-android --appIdSuffix validSuffix` runs properly
Closes https://github.com/facebook/react-native/pull/13169
Differential Revision: D4823391
Pulled By: ericvicenti
fbshipit-source-id: 31ed35fd79403804b4781e81eb49f1c4627d7f8e
Summary:
One of my changeset broke the "ModuleGraph" code without warning earlier because we are using `any`, that equivalent to having no typing at all. This changeset fixes the types so that `ResolutionRequest` is exactly what it actually is: a class usable for any `Module`-looking class, including the normal one, and the "ModuleGraph" one used for Buck builds. That way, the ModuleGraph's `Module` is typechecked against `Moduleish`.
Concretely this change mostly migrates the `Module` to its generic parameter counterpart `TModule` inside `ResolutionRequest`.
Reviewed By: kentaromiura
Differential Revision: D4826256
fbshipit-source-id: fcd7ca08ac6c35e4e9ca983e2aab260e352bcb4e
Summary:
…th RCTSharedApplication()
Thanks for submitting a PR! Please read these instructions carefully:
- [ ] Explain the **motivation** for making this change.
Using React Native latest version with Cocoapods 1.2.0 causes the following error inside iOS app extensions
> /react-native/React/Modules/RCTAccessibilityManager.m:67:70: ‘sharedApplication’ is unavailable: not available on iOS (App Extension) — Use view controller based solutions where appropriate instead.
Moving the use of [UIApplication sharedApplication] to RCTSharedApplication() which is safe on app extension
- [ ] Provide a **test plan** demonstrating that the code is solid.
I am not sure how to test such that all the features which touch the modified code are tested.
- [ ] 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?
Using React Native latest v
Closes https://github.com/facebook/react-native/pull/13227
Differential Revision: D4816338
Pulled By: javache
fbshipit-source-id: e3e3c77882990ad1817b0b633521cff52571ecd0
Summary:
This PR depends on #13172
Packager events are mostly logged through the TerminalReporter by default (#13172 makes this configurable). But there are a few things that aren't passed through TerminalReporter.
- We [log a banner with some information about the port and what's going on](8c7b32d5f1/local-cli/server/server.js (L22-L32))
- Also [a message about looking for JS files](8c7b32d5f1/local-cli/server/server.js (L34-L38)) (not sure what that is for / if it is useful beyond telling the user what directory root they started the packager in, but that's another thing).
- If the packager fails to start, then [we log an error message](8c7b32d5f1/local-cli/server/server.js (L41-L61)).
This pull request changes those log messages to be handled by TerminalReporter. I tri
Closes https://github.com/facebook/react-native/pull/13209
Differential Revision: D4809759
Pulled By: davidaurelio
fbshipit-source-id: 2c427ec0c1accaf54bf6b2d1da882cd6bfaa7829
Summary:
In Expo tools such as XDE, exp we listen listen to stdout from the packager process and print it in our own buffer. In the case of XDE, an electron app, our log pane is DOM-based, and before printing each log chunk we need to remove special tty characters and sometimes parse it to get information that we need (eg: progress bar). By using a custom reporter, we can take the raw events and pass them along in a format that is easy to consume by XDE and exp. This same motivation applies to create-react-native-app, where we currently don't show a progress bar in the terminal, but we can with this change.
Create `LogReporter.js` in the root of a project with the CLI changes included in this PR.
```
class LogReporter {
update(event) {
console.log(JSON.stringify(event));
}
}
module.exports = LogReporter;
```
Now, run `react-native start --customLogReporterPath=LogReporter.js` -- all of the raw events will be output as JSON (while the logs
Closes https://github.com/facebook/react-native/pull/13172
Differential Revision: D4795760
Pulled By: hramos
fbshipit-source-id: 80164b2f30e33a3f9965f4865a8404f8640a52c1
Summary:
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.
At the moment, if you uncomment the react specific code in `build.gradle` you'll get a compilation error. Adding a comma prevents this error.
No tests are necessary. This is a simple fix.
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/martink
Closes https://github.com/facebook/react-native/pull/13212
Differential Revision: D4802065
Pulled By: javache
fbshipit-source-id: 0ddfe16241381d7e4ac0e48be1bada21d9df2068
Summary:
This changes the single quotes to double quotes so this command can be copy-pasted.
If a user copy pastes the run-on-device example in bash they will be presented with a confusing prompt because bash expects another terminating single quote.
```
~ben (master *) ~/code/transit: react-native run-ios --device 'Max's iPhone'
>
>
```
It seems minor but this could be just confusing enough to frustrate a beginner or someone not familiar with bash.
This can be tested by running:
```
react-native run-ios --help
```
and verifying that the "run on device" example is changed:
```diff
- react-native run-ios --device 'Max's iPhone'
+ react-native run-ios --device "Max's iPhone"
```
Closes https://github.com/facebook/react-native/pull/13145
Differential Revision: D4776305
Pulled By: hramos
fbshipit-source-id: 9500551bfc106cd1687468f7ecc4c91089e1f703
Summary:
Adds a new checkbox to the Chrome Debugger page that prevents the tab from being deprioritized by Google Chrome.
This is accomplished by embedding an inaudible sound byte (in 10Hz range) that loops on a low volume.
Reviewed By: kassens
Differential Revision: D4786288
fbshipit-source-id: 949d96ed3c0eac92ad56cdd119418df9ec6d0846
Summary:
Refactors JavaScript in the `debugger.html` used to operate the Chrome Debugger.
- Pull out all view-related logic into a global `Page` object.
- Persist the dark theme across debug sessions using `localStorage`.
Reviewed By: kassens
Differential Revision: D4786235
fbshipit-source-id: ab959d1c95465a10b4538b14d9c87a51ae3b7078
Summary:
**Motivation**
Resolves issue: #12367. The issue is that the packager does not launch automatically on Windows when running `react-native run-android` like it does on OSX. The proposed change fixes this issue, and causes the packager to be launched automatically on Windows 10. Also note the updated code uses the syntax described in the [Node.js documentation](https://nodejs.org/api/all.html#child_process_spawning_bat_and_cmd_files_on_windows) on spawning .bat files on Windows.
**Test plan**
Manually tested on Windows 10.
Running just `react-native run-android` now results in the packager launching, without needing to run `react-native start` in a new command prompt window.
**Screenshot:**
Closes https://github.com/facebook/react-native/pull/12755
Differential Revision: D4767321
fbshipit-source-id: a14f369ba99939aa44d0ee3403e1d262e2657e6e
Avik Chaudhuri
Pieter De Baets
James Burnett
Christoph Pojer
Andrew Imm
Tim Yung
Adam Miskiewicz
Daniel Friesen
Jean Lauliac
Kevin Gozali
Gabriel Laet
chunghe
Hugo Dozois
Max Thorson
glevi@fb.com
David Aurelio
Gabe Levi
eacaps
Max Sherman
Dan Abramov
Lukas Piatkowski
Sokovikov
Ashok Menon
Paulus Esterhazy
Brian Vaughn
Karan Thakkar
Andres Suarez
Adam Perry
Vojtech Novak
Fred Blau
Sai Grandhi
Jhen
Shruti Malugu
Koen Punt
Brent Vatne
Sam Corcos
Build Service
Benjamin Eckel
jrodiger
Yann Pringault
