Deprecation of readerFromStreamReader seems to have no direct replacement from Readable to Reader

[andrewthauer]

Describe the bug

I'm unable to find a replacement for the deprecated readerFromStreamReader when trying to map a steams API Readable to a stdlib Reader

Steps to Reproduce

// old code
const fileReader = (await Deno.open(tarballPath, { read: true }))
  .readable
  .pipeThrough(new DecompressionStream('gzip'))
  .getReader();
const untar = new Untar(readerFromStreamReader(fileReader));

// trying to get this to work
const fileReader = (await Deno.open(tarballPath, { read: true }))
  .readable
  .pipeThrough(new DecompressionStream('gzip'))
  .getReader();
const untar = new Untar(fileReader);
//    is not compatible ^^^^^^^^^^ getReader.read() vs Reader.read(uint)

Expected behavior

I should be able to go from an Deno.FsFile while using a pipeThrough to a Reader in order to use some of the stdlib APIs like tar, etc.

If there is a way to convert this without writing custom code, this should be documented. Otherwise we should re-consider deprecating readerFromStreamReader.

Environment

• OS: macOS Ventura arm64
• deno version: 1.40.3
• std version: 0.215.0

[iuioiua]

This is a valid use case for un-deprecating readerFromStreamReader(). See #4343.

[andrewthauer]

@iuioiua - Thanks for looking at this.

However, this actually makes me wonder why the Deno.Reader and stdlib Reader interfaces do not conform to the Streams API ReadableStreamDefaultReader interface instead? I'm sure there is probably a good reason for this, but as an outsider this seems a bit backwards to me.

[nberlette]

@andrewthauer

However, this actually makes me wonder why the Deno.Reader and stdlib Reader interfaces do not conform to the Streams API ReadableStreamDefaultReader interface instead? I'm sure there is probably a good reason for this, but as an outsider this seems a bit backwards to me.

I was a bit puzzled by the deviation of Deno.Reader and the stdlib Reader interfaces from the Streams API ReadableStreamDefaultReader myself. After digging around a bit, it seems they were directly inspired by Go's IO and streaming APIs, including their synchronous versions. This Go-inspiration is also very apparent in stdlib modules like BufReader, which even has a shoutout to Go in its JSDoc comments.

As Deno 2.0 shifts towards web streams, it appears it will phase out Go-style buffers, suggesting a move away from utilities like readerFromStreamReader. However, the plan for synchronous APIs like ReaderSync and WriterSync is less clear. The deprecations hint at their complete removal, which could disrupt modules relying synchronous ops that have been a staple in the Deno ecosystem for many years. A relevant example is Deno.stdout.writeSync(), which many projects and modules rely upon (see wait by denosaurs).

Given no direct Web Streams equivalents, this raises questions about the migration path for these synchronous methods. It's unclear why a hybrid model allowing both ReadableStream / WritableStream and synchronous APIs can't be considered, similar to the approach that's being used now in Deno.FsFile.

If there's a misunderstanding on my part regarding the documentation or the migration strategy, please let me know. I'm eager to continue to stay up to date with Deno as it grows and evolves.

Thanks,
Nick

[andrewthauer]

Interesting. I know a Deno started in go and has been influenced by go to varying degrees. I think most of the parts that show through in this regard are the good parts. It does still seem a bit odd that given the push to use JS web standards like the Streams API (a good thing imo), the underlying Deno primitives differ and don't seem to be compatible (e.g. Deno.Reader/Writer, stdlib Reader/Writer).

As an end user of this, I don't feel like I should need to reach for a conversion function to adapt one to the other. I haven't tried going from Reader/Writer back to the Streams API, but don't recall seeing an inverse function from readerFromStreamReader at all in stdlib. Maybe not required?

[kt3k]

We once planned to deprecate and remove the entire Reader / Writer interfaces at some point in favor of Web Streams, but recently we think that the plan is not feasible regarding the ecosystem impact.

Web Streams based APIs are still recommended way to perform most of I/O operations in Deno, but we don't remove existing read / write methods in Deno runtime, and utilities (including types, helper functions, etc) for them will be kept in std/io.

[andrewthauer]

Thanks for the explanation @kt3k!

We once planned to deprecate and remove the entire Reader / Writer interfaces at some point in favor of Web Streams, but recently we think that the plan is not feasible regarding the ecosystem impact.

Given the lead up and evolution of the io based APIs & Streams API it makes sense not to rock the boat to much. Honestly, some of the deprecations around io & streams have been a bit of a pain to both figure out migration paths and to find non trivial conversion examples.

Web Streams based APIs are still recommended way to perform most of I/O operations in Deno, but we don't remove existing read / write methods in Deno runtime, and utilities (including types, helper functions, etc) for them will be kept in std/io

Agree. It seems required for some cases like the one raised in this issue. It would be nice if one didn't have to think about and/or know how to convert from one to another.

I wonder how feasible it would be to have stdlib functions could be extended to also accept both the Reader/Writer & ReadableStream/WriteableStream and then do the conversion internally?

[iuioiua]

I wonder how feasible it would be to have stdlib functions could be extended to also accept both the Reader/Writer & ReadableStream/WriteableStream and then do the conversion internally?

It's simpler to troubleshoot and use the corresponding function for a given type.