If specified, instead of capturing the output, the child process stdout
will be piped to the destination stream.
Although the standard spawn stdio option lets you pass in streams,
these have to be connected to an open file descriptor. The destination
option allows you to use any Writable, so it can be used with a
Transform for instance.
This fixes an issue where starting up the Android Emulator with stdio
piped would only exit when the emulator exits, instead of when the app
is successfully installed, thus blocking further startup.
The reason for this was that cordova-lib superspawn listens for the
‘close’ event of its child process, which is emitted when the stdio
streams have all terminated. If those streams are shared with other
processes (such as further child processes spawned by the child
process), that means we won't receive a 'close' until all processes
have exited, so we should listen for 'exit' instead.
The execFileSync function is meant to resemble the similarly-named Node
0.12 synchronous process creation API, but instead of being fully
blocking it uses a promise-based implementation. You can also use
execFileAsync directly, which returns a promise.
Some functionality is currently missing but could be added when the
need arises (e.g. support for timeout, maxBuffer, and encoding options).
Eventually, these versions should replace the ones in
tools/utils/utils.js and tools/tool-testing/selftest.js.
We now create a temporary directory with a generated config.xml
to use as a template for creating the Cordova project. This way, we are
not dependent on the contents of cordova-app-hello-world but we base
our initial project state on our own defaults and optionally a
mobile-config.js.
This change was in part motivated by a bug in Cordova where changing
the app name to a version with a different case, on a case insensitive
file system like OS X, means the project will no longer build. Because
our app name on creation was based on the project directory and we
didn’t respect the app name set in mobile-config.js until the first
build, there was always a rename needed, triggering the bug.
This bug affected both the todos and localmarket example apps.
Using cordova.raw.run() would swallow the error superspawn created from
the underlying error output, so we’re now calling the platform run
script ourselves and potentially receive an error through the promise.
Not relying on cordova-lib also means preparing the platform is no
longer done automatically for us. This means you'll have to make sure
CordovaProject#prepareForPlatform() is called before running. We do
this for all the current run target’s platforms in
CordovaRunner#prepareProject().
(We don’t do it automatically within CordovaProject#run because this
way the prepare is not part of ‘Starting …’, and also because running
multiple targets of the same platform would mean unnecessarily running
prepare multiple times).
This would likely involve some kind of concurrent progress display, but
we might also need to revise logging as we don’t want ongoing logs to
mess up the progress status.
