Add result.ipc/error.ipc by ehmicky · Pull Request #1067 · sindresorhus/execa (original) (raw)

result.ipc

This PR adds result.ipc/error.ipc. It is an array with all the IPC messages sent by the subprocess to the current process. In many ways, it is similar to result.stdout, but for IPC messages.

This array is only defined when the ipc option is true.

Disabling or limiting

The buffer and maxBuffer options apply to result.ipc the same way they apply to result.stdout. This means the user can turn this off using buffer: false or buffer: {ipc: false}. Or limit the max amount of buffered IPC messages using maxBuffer: {ipc: 100}.

Return any type from a subprocess

With the above, users now have a simple way to return almost any type from a Node.js subprocess. That's pretty nice!

Also, for IPC users, this removes the need for manual getOneMessage()/getEachMessage() calls in many situations.

// main.js import {execaNode} from 'execa';

const {ipc} = await execaNodebuild.js; console.log(ipc[0]); // {kind: 'start', timestamp: date} console.log(ipc[1]); // {kind: 'stop', timestamp: date}

// build.js import {sendMessage} from 'execa';

await sendMessage({kind: 'start', timestamp: new Date()}); await runBuild(); await sendMessage({kind: 'stop', timestamp: new Date()});

Debugging

error.ipc is also quite useful when debugging IPC-related problems.

Additionally, IPC messages are now printed at the end of the error message. This is just like stdout/stderr, i.e. treating them as just another kind of output from the subprocess. This can be turned off with buffer: {ipc: false} too.

Stability

This PR also improves error handling, to make IPC more stable. If getOneMessage(), getEachMessage() or sendMessage() error, the IPC channel is now automatically disconnected. Since those methods error by throwing an exception, one of the processes is likely to stop sending/receiving messages. In many situations, this would leave the other process hanging forever. Hanging processes are hard to debug.

Also, if one process disconnects while the other one is waiting with getOneMessage(), we now make that getOneMessage() throw, as opposed to letting it hang forever.