ehmicky
ehmicky
It's taken me quite some time, but I finally got this working. I have a PR at #912 which implements this, together with `.readable()` and `.writable()` methods. ## Motivation The...
One of the issues with `Duplex.from()` is that it is not designed to create read-only or write-only streams. It is possible to do it, but it is still a `Duplex`...
Per [this comment](https://github.com/sindresorhus/execa/issues/877#issuecomment-1982195398), we are going to name the property `subprocess` instead.
Done in #643: one can now use `stdout: ['inherit', 'pipe']` to get that behavior. This works also with `stderr` and `stdin`.
The problem is this: when using the `all` option, we currently guarantee the order of the `stdout` writes (on their own), of the `stderr` writes (on their own), but not...
I did some additional research into this. The bottom line is: this behavior is inherited from Node.js and I do not think we cannot change, although users can use some...
Revisiting this issue, I think our current implementation of `killSignal` is inconsistent: - It is used by the `timeout` and `signal` options. - It is not used by the `cleanup`...
It appears that this PR might be stalled. Also, it seems like using a `TransformStream` might now be more proper than a `Duplex`? In terms of implementation, I am wondering...
For similar reasons as `Buffer` vs `Uint8Array`: web streams can be used in both browsers and Node.js. However, `Duplex` is fine too, considering it is easy to convert using `Stream.Duplex.toWeb(duplex)`....
TypeScript 3.4 is old now, so we can close this.