Open drzraf opened 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. 😉
I'm currently wrapping manually my project's
ReadableStream
and evaluating if I could even useweb-stream-polyfill
to make the project run on FF < 69 (which lackBlob.stream()
).But I wonder whether such a work isn't better handled by
core.js
+browserlist
. Did you planned contributing this polyfill tocore.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
)