You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
What's happening with writeAll and writeAllSync? #6284
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.writeSyncboth 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 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.
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.
Activity
kt3k commentedon Dec 20, 2024
We consider Web Streams (ReadableStream and WritableStream) as the main way of I/O in Deno denoland/deno#11288 denoland/deno#9795
writeandwriteSyncremain there only for backward compatibility purpose.The recommended way for writing things to stdout is something like:
lionel-rowe commentedon Dec 20, 2024
@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
writeSyncand is basically exactly the same aswriteAllSync, while the async version uses aResponseobject (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 supplypreventClose: truewill cause all future attempts to write to stdout to throw errors.kt3k commentedon Dec 20, 2024
Maybe we can consider making
stdout.writeSyncwork likewriteAllSync.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.