What's happening with writeAll and writeAllSync?

[lionel-rowe]

Context:

• Deno.writeAll and Deno.writeAllSync were deprecated and then removed.
• writeAll and writeAllSync of @std/streams were deprecated, moved to @std/io, and then removed.
• Per stabilize @std/io #5003, @std/io is no longer due for stabilization in order to "to nudge people to use @std/streams instead".
• Docs for Deno.stdout.write and Deno.stdout.writeSync both warn that "It is not guaranteed that the full buffer will be written in a single call" (as do the corresponding methods of Deno.stderr).

In light of all that, what if anything is the stabilization path for a high-level "write all this stuff to stdout/stderr (with no newline at the end) and definitely don't bail part-way through" method in Deno/std?

Conversely, is there any reason for that method not to simply be Deno.std(out|err).write(Sync)?? I'm struggling to think of any low-level use case where it'd be preferable to bail part-way through in an unspecified way (as opposed to, say, relying on userland code to chunk/paginate the input as appropriate).

[kt3k]

We consider Web Streams (ReadableStream and WritableStream) as the main way of I/O in Deno denoland/deno#11288 denoland/deno#9795

write and writeSync remain there only for backward compatibility purpose.

The recommended way for writing things to stdout is something like:

await dataSource.pipeTo(Deno.stdout.writable, { preventClose: true });

[lionel-rowe]

await dataSource.pipeTo(Deno.stdout.writable, { preventClose: true });

@kt3k That only works for async scenarios, though.

For context, I was revisiting an old StackOverflow answer of mine and I realized it wasn't correct, so I updated it with what I think (?) are the best/simplest ways of doing this as of end-of-2024. But neither of them are completely trivial; the sync version uses writeSync and is basically exactly the same as writeAllSync, while the async version uses a Response object (seems to be the simplest way of converting a string/u8 array to a u8 readable stream, but does it create it unnecessary overhead?) and has a significant gotcha in that forgetting to supply preventClose: true will cause all future attempts to write to stdout to throw errors.

[kt3k]

Maybe we can consider making stdout.writeSync work like writeAllSync.

I'm struggling to think of any low-level use case where it'd be preferable to bail part-way through in an unspecified way (as opposed to, say, relying on userland code to chunk/paginate the input as appropriate).

I agree with this. The current behavior doesn't seem useful/ergonomic.

Can you create an issue for it in Deno CLI repo?

---

I currently don't have any idea about how to improve the async version. Any suggestions are welcome.