Incorrect typings for ReadableStream

[ondras]

Hi,

my code uses the following tsconfig lib declaration:

"lib": ["dom", "dom.iterable", "deno.ns"],

after updating to Deno 1.3.1, the following TS error emerges:

error: TS2339 [ERROR]: Property 'getIterator' does not exist on type 'ReadableStream<R>'.
  return res.readable.getIterator();
                      ~~~~~~~~~~~
    at https://deno.land/[email protected]/async/pool.ts:45:23

...which is preventing me from running the code.

Thanks,
O.

[lucacasonato]

I don't think this is a Deno issue. It seems the 'dom' type library (from typescript) doesn't include types for getIterator. So this looks like a upstream typescript issue.

[kitsonk]

Actually, we have a challenge. The specification was updated in June and getIterator() was renamed to values(). It was never implemented in Chrome as getIterator(). I guess this is the problem with implementing perpetually draft specifications. 🤷

[kitsonk]

Actually looking at that now, there is a whole load of changes there... 😭 it needs to be gone through with a fine toothed comb and realigned.

[ondras]

Is there at least a way to temporarily monkey-patch this (such as interface ReadableStream { getIterator ... }) so the code using the dom lib can be executed?

[kitsonk]

Interfaces are open ended. Something like this should work in your main module, assuming it is TypeScript:

declare global {
  interface ReadableStream<R = any> {
    getIterator(options?: { preventCancel?: boolean }): AsyncIterableIterator<R>;
  }
}

[ondras]

Interfaces are open ended. Something like this should work in your main module, assuming it is TypeScript:

Great, thanks @kitsonk!

(my naïve attempts were missing the declare global statement, thus failing to fix stuff)

[lucacasonato]

Actually, we have a challenge. The specification was updated in June and getIterator() was renamed to values(). It was never implemented in Chrome as getIterator(). I guess this is the problem with implementing perpetually draft specifications. 🤷

Oh no! I was worried this was the case. This is going to definitely be a breaking change to fix, and it is going to break std types again 😭.

[kitsonk]

I suspect we can have values() and getIterator() for now and move all std over to values().

[timonson]

This error still comes up. Is there a workaround?

[ondras]

This error still comes up. Is there a workaround?

The code mentioned in #7217 (comment) is a suitable workaround for my use case.

[timonson]

It works indeed, thank you @ondras ! I misread kitsonk's comment the first time.

[lucacasonato]

This was resolved in #9103.