[@types/node] More issues with ReadableStream types

[james-pre]

I saw a few other discussions concerning ReadableStream...

• [@types/node] ReadableStream type definition here is not compatible with TypeScript's #65542
• [@types/node] ReadableStream from node:stream/web is not compatible with web.d.ts version #73121
• [@types/node] module 'stream/web' should be updated to reflect TS dom types changes #72102

This time there is an issue with the return type of Readable.toWeb not actually returning a type compatible with ReadableStream.
For example, const stream: ReadableStream = Readable.toWeb(...) gives this absurd TS error:

Argument of type 'import("node:stream/web").ReadableStream<any>' is not assignable to parameter of type 'ReadableStream<any>'.
  Types of property 'pipeThrough' are incompatible.
    Type '<T>(transform: import("node:stream/web").ReadableWritablePair<T, any>, options?: import("node:stream/web").StreamPipeOptions | undefined) => import("node:stream/web").ReadableStream<T>' is not assignable to type '<T>(transform: ReadableWritablePair<T, any>, options?: StreamPipeOptions | undefined) => ReadableStream<T>'.
      Types of parameters 'transform' and 'transform' are incompatible.
        Type 'ReadableWritablePair<T, any>' is not assignable to type 'ReadableWritablePair<T | undefined, any>'.
          The types of 'readable.pipeThrough' are incompatible between these types.
            Type '<T>(transform: ReadableWritablePair<T, T>, options?: StreamPipeOptions | undefined) => ReadableStream<T>' is not assignable to type '<T>(transform: ReadableWritablePair<T, T | undefined>, options?: StreamPipeOptions | undefined) => ReadableStream<T>'.
              Types of parameters 'transform' and 'transform' are incompatible.
                Type 'ReadableWritablePair<T, T | undefined>' is not assignable to type 'ReadableWritablePair<T | undefined, T>'.
                  The types of 'readable.getReader(...).read' are incompatible between these types.
                    Type '<T extends NodeJS.NonSharedArrayBufferView>(view: T, options?: ReadableStreamBYOBReaderReadOptions | undefined) => Promise<ReadableStreamReadResult<T>>' is not assignable to type '<T extends Exclude<BufferSource, ArrayBuffer>>(view: T, options?: ReadableStreamBYOBReaderReadOptions | undefined) => Promise<ReadableStreamReadResult<T>>'.
                      Types of parameters 'view' and 'view' are incompatible.
                        Type 'T' is not assignable to type 'NonSharedArrayBufferView'.
                          Type 'ArrayBufferView<ArrayBuffer>' is not assignable to type 'NonSharedArrayBufferView'.
                            Type 'ArrayBufferView<ArrayBuffer>' is missing the following properties from type 'DataView<ArrayBuffer>': getFloat32, getFloat64, getInt8, getInt16, and 19 more.
                              Type 'T' is not assignable to type 'DataView<ArrayBuffer>'.
                                Type 'ArrayBufferView<ArrayBuffer>' is missing the following properties from type 'DataView<ArrayBuffer>': getFloat32, getFloat64, getInt8, getInt16, and 19 more.

Note that Typescript v6.0.2 is in use.

[typescript-bot]

Thanks for the discussion about "node", some useful links for everyone:

• npm
• DT
• Related discussions

Pinging the DT module owners: @microsoft, @jkomyno, @r3nya, @btoueg, @Touffy, @mohsen1, @galkin, @eps1lon, @WilcoBakker, @chyzwar, @trivikr, @yoursunny, @qwelias, @ExE-Boss, @peterblazejewicz, @addaleax, @victorperin, @nodejs, @LinusU, @wafuwafu13, @mcollina, @Semigradsky, @Renegade334, @anonrig.

[Renegade334]

The @types/node web types and the lib.dom web types simply do not interassign.

To avoid mixing the two, either:

• remove lib.dom from your tsconfig, so that the globals come from @types/node and not from elsewhere
• import the @types/node ReadableStream explicitly from the node:stream module

[james-pre]

Given that both interfaces should implement the same API, is there any reason why one isn't assignable to the other? I'd think that means one of them doesn't have the correct types.

[Renegade334]

It's not quite that simple, sadly... this error occurs even if the definitions are byte-for-byte identical, due to an inference limitation in the type checker.

It comes down to the generic methods pipeTo and pipeThrough. During the deep assignability checks, the checker does some inferring of some generic type parameters for ReadableWritablePair types in the deep expansion. The type parameters are inferred indirectly from ReadableStream/WritableStream method signatures in the target interface, and when this happens, the checker ends up inferring a ReadableWritablePair type parameter as T | undefined, not T. This is unavoidable given the shape of the interfaces and the limitations of the type checker.

Because those generic methods see ReadableStream in both covariant and contravariant context (since it appears in both the transform argument type and the return type), the checker performs this inference process differently in each context, and this ends up with one side computing a ReadableWritablePair<T | undefined, T> and the other side computing a ReadableWritablePair<T, T | undefined>. These aren't interassignable, meaning that the checker invariably reports a mismatch error.

These assignability checks are bypassed when the ReadableStream symbols are identical (ie. both @types/node or both lib.dom), and identical type symbols also short-circuit type parameter inference, meaning that these errors don't occur.

[james-pre]

Thanks for the in-depth explaination. I wonder if it's possible to get it to be compatible somehow. Maybe even it would be possible to use the lib.dom.

It would be great if the annoyance of having to cast could be fixed, though I don't have all the answers.