Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

core-js integration? #16

Open
drzraf opened this issue Jan 27, 2021 · 1 comment
Open

core-js integration? #16

drzraf opened this issue Jan 27, 2021 · 1 comment

Comments

@drzraf
Copy link

drzraf commented Jan 27, 2021

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
Copy link
Owner

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. 😉

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants