Add ReadableStream and WritableStream to NoStreamStdioOption

[rovo89]

Not 100% sure about this one, but when passing a WritableStream for stdout/stderr, it doesn't flag those variables as possibly undefined. My understanding is that the streams are pretty much equivalent when it comes to collecting the output or not.

[ehmicky]

Hi @rovo89,

When a WritableStream is passed to the stdout or stderr option, subprocess.stdout is a stream, not undefined. result.stdout is also defined. So the current types appear to be correct?

[rovo89]

Oh OK, so there is different behavior between passing Writable and WritableStream? I thought that "features" of one also apply to the other, therefore I was confused to see that I got a type warning for the former and not for the latter.

Which kind of stream do we get then? A ReadableStream when we pass in a WritableStream? Didn't find docs for that.

[ehmicky]

Yes, the behavior is different.

Execa is a wrapper around node:child_process. At the moment, the Node.js core module only uses Node.js streams, not web streams. Execa adds support for web streams in a few different ways, but to do so it uses 'pipe' under the hood, and manually creates and pipes web streams.

The documentation about it is here. subprocess.stdout is always a Node.js Writable, except when it is null. The documentation mentions when it can be null.

[rovo89]

OK, thanks for the clarification. My thought was that if I pass a stream and nothing else, the command sends the output there and then it's "lost". Actually, my case was about result.stderr, i.e. after awaiting, and since I didn't expect the output to be buffered, I thought that I couldn't access it at that point. So no sense in passing pipe and my stream if I want to both pass it to my logs and analyze it. 😉