Update Streams API to match the latest IDL

[saschanaz]

whatwg/streams#1035 did a massive work to introduce Web IDL, and that made our IDL outdated in complex way. Updating our code to use the upstream IDL will ease getting further update from this spec.

Pinging Mattias Buelens (@MattiasBuelens) who might be interested.

[MattiasBuelens]

Thanks for the ping. I'm indeed interested, I've even already started working on this in my fork, see this streams-webidl branch. 😁

In your comment on #827, you mentioned that it wasn't appropriate to add WritableStream.abort() because Chromium has the only implementation. The same argument can be made for this Web IDL rework. What's our stance on this? Do we want TypeScript to be up-to-date with the specification, even though most browsers aren't up-to-date yet? (This is also the main reason why I haven't yet opened a pull request for this.)

Perhaps we could remove a bunch of types, properties and methods that are not yet supported in most browsers by adding them to inputfiles/removedTypes.json? For example, readable byte streams are currently not implemented by any browser (not even Chromium), so maybe we should remove all definitions related to that (e.g. UnderlyingByteSource, ReadableByteStreamController, ReadableStreamBYOBReader, etc.)? Then, once browsers start implementing this feature, we can bring those types back. We could maybe do the same for features that are only supported by a single browser, although that would remove a lot of types (such as WritableStream and TransformStream)... 😞

If we do decide to update our type definitions, then should we also update all type names to match those from the Web IDL? For example, I had added a PipeOptions interface to represent the second argument for pipeTo() and pipeThrough(), since previously it didn't have a name. After the Web IDL rework, this type now has an official name: StreamPipeOptions. Should we rename our PipeOptions to StreamPipeOptions (and force users to update their code)? I suppose that TypeScript is less concerned with backwards compatibility, and more with following the standards. And since the standard has changed in a (slightly) backwards incompatible way, TypeScript is also allowed to change as such?

[saschanaz]

Perhaps we could remove a bunch of types, properties and methods that are not yet supported in most browsers by adding them to inputfiles/removedTypes.json?

Yes, that's what I have done. It shouldn't cause any compatibility problem as those have never really existed.

We could maybe do the same for features that are only supported by a single browser, although that would remove a lot of types (such as WritableStream and TransformStream)... 😞

After the Web IDL rework, this type now has an official name: StreamPipeOptions. Should we rename our PipeOptions to StreamPipeOptions (and force users to update their code)?

I vote for removing and renaming but since it may cause a compat problem, Nathan Shively-Sanders (@sandersn) might have some idea.

[MattiasBuelens]

If we're going to remove everything that is not supported in at least two browser engines, there won't be a whole lot left. Looking at the compatibility data from MDN and the test results from wpt.fyi, we have:

• ReadableStream constructor (with UnderlyingSource and ReadableStreamDefaultController) (Chromium, Firefox, Safari)
• ReadableStream.cancel() (Chromium, Firefox, Safari)
• ReadableStream.getReader() (Chromium, Firefox, Safari)
• ReadableStream.locked (Chromium, Firefox, Safari)
• ReadableStream.tee() (Chromium, Firefox, Safari)
• ByteLengthQueuingStrategy (Chromium, Firefox, Safari)
• CountQueuingStrategy (Chromium, Firefox, Safari)

We wouldn't even need to worry about renaming PipeOptions, since only Chrome has support for pipeTo() and WritableStreams anyway. 😛

If we do decide to remove the Chromium-only classes/methods/properties from the DOM types, does that mean we have to bring back @types/whatwg-streams? 😕 We had deprecated that in favor of TypeScript's built-in definitions, see DefinitelyTyped/DefinitelyTyped#38785.

[MattiasBuelens]

Hang on, it looks like WebKit does have a fairly complete implementation? It looks like it's been worked on recently, but I can't seem to find whether this is enabled by default or not...

Firefox also appears to be working on WritableStreams behind the javascript.options.writable_streams flag.

Maybe there's still hope? 😀

---

EDIT: Never mind, the WebKit implementation is outdated. For example, WritableStream doesn't even have getWriter(), instead it has write()/abort()/close() on the stream itself, like in a very old version of the spec. The only recent changes seem to be related to a few build flags... 😞

Firefox's WritableStream implementation looks fairly up-to-date. However, there's no pipeTo/pipeThrough just yet, so we'd still need to remove those methods. And it's still behind a flag...

[saschanaz]

I'm okay to keep Chromium-only types in this specific case as 1) keeping them will prevent compatibility issue and 2) we expect others to eventually get them. (Edit: I mean for types that doesn't need to be renamed. Otherwise they will cause compat issue anyway, so I vote for removing them.)

Maybe we can first remove types that never implemented and think about others.

[MattiasBuelens]

I've opened a draft PR: #890.

Hopefully, we can get a better idea of the impact by looking at what the changes will actually look like. 😁

[Banou26]

Could we re-add the types of UnderlyingByteSource, ReadableByteStreamController, ReadableStreamBYOBReader, ect... now that pretty much all evergreen browsers supports them? Firefox shipped them with 102 and chromium browsers have been supporting them for a while.

Edit: Just found out about #1362