@vltpkg/promise-spawn
Spawn a process and return a promise that resolves when the process closes. Fork of @npmcli/promise-spawn
.
Differences from @npmcli/promise-spawn
- A
SpawnPromise(cmd, args, options)
class is added that handles most of the functionality. promiseSpawn.open()
is removed- When run as root, it just runs the command as root, it doesn’t try to infer the uid/gid based on the owner of the cwd..
- No special handling for
shell: true
processes, and thus, no escaping of arguments in that case. (It’s just passed through to Node’sspawn()
method.) - Fully type-aware, even down to inferring the presence and type
of
stdout
andstderr
properties, as well as the properties added via the optionalextra
argument.
Usage
API
promiseSpawn(cmd, args, opts, extra)
-> Promise
Run the command, return a Promise that resolves/rejects based on the process result.
Result or error will be decorated with the properties in the extra
object. You can use this to attach some helpful info about why the
command is being run, if it makes sense for your use case.
If stdio
is set to anything other than 'inherit'
, then the result/error
will be decorated with stdout
and stderr
values. If stdioString
is
set to true
, these will be strings. Otherwise they will be Buffer
objects.
Returned promise is decorated with the stdin
stream if the process is set
to pipe from stdin
. Writing to this stream writes to the stdin
of the
spawned process.
Options
stdioString
Boolean, defaulttrue
. Return stdout/stderr output as trimmed strings rather than buffers.acceptFail
Boolean, defaultfalse
. If true, then a process that closes withstatus
other than 0, orsignal
other thannull
, will reject the promise. If true, then failure exits resolve the promise normally. This is useful when you need to run a process where an exit status of>0
is informative, to avoid creating an Error object for it.- Any other options for
child_process.spawn
can be passed as well.
TypeScript Inference Caveats
Workaround:
If you provide a complex stdio option like ['pipe', 'inherit']
,
then this will of course mean that stdin
is set to a writable
stream, stderr
is set to a readable stream (because that’s the
default), but stdout
is set to null
.
The types will accurately infer this from the type of the argument. However, observe this incorrect result:
TS will infer the options.stdio
property to be ('pipe' | 'inherit')[]
. Since the second item of such an array might be
set to 'pipe'
at some point, TS will infer the return value to
include { stdout: string }
.
To get around this, typecast the field to its literal value. This is a bit noisy, but works fine:
When given a single argument to apply to all stdio
fields, this
inference happens correctly by default.