MattiasBuelens / web-streams-adapter

Adapters for converting between different implementations of WHATWG Streams
MIT License
32 stars 1 forks source link

core-js integration? #16

Open drzraf opened 3 years ago

drzraf commented 3 years ago

I'm currently wrapping manually my project's ReadableStream and evaluating if I could even use web-stream-polyfill to make the project run on FF < 69 (which lack Blob.stream()).

But I wonder whether such a work isn't better handled by core.js + browserlist. Did you planned contributing this polyfill to core.js so that Babel transpilation (@babel/preset-env) would automatically do the necessary wrapping (and bundle the polyfill) when needed, according to requested browserlist?

Note: I also wonder down to which FF, Chrome, IE version the polyfill apply? (In particular Blog.stream)

MattiasBuelens commented 3 years ago

I don't have plans to integrate this in core-js. That project is mostly focused on polyfilling ECMAScript APIs such as Math or Array. I did notice that they have polyfills for some web APIs like URL, but that's very limited. For example, they also don't try to polyfill fetch.

There are also risks involved with trying to patch up all web APIs that may return or accept a ReadableStream. For example, if we'd try to patch up the new Response() constructor to accept a polyfilled stream as its body, then we might break FetchEvent.respondWith(response) inside service workers because the browser no longer recognizes this as a valid native Response object.

In the long term, I expect a better solution would be to have web-streams-polyfill patch up the existing ReadableStream class with the missing properties and methods, rather than creating a separate class. That way, a polyfilled stream would still be a "real" native ReadableStream, and we could more confidently use it in polyfills for other APIs. We wouldn't even need this web-streams-adapter project anymore! It's not going to be easy though, follow MattiasBuelens/web-streams-polyfill#20 if you're interested. 😉