window.fetch method implementation

[chicoxyzzy]

just noticed core-js missing fetch polyfill
subjectively best existing implemetation https://github.com/github/fetch

[zloirock]

It's missing because currently core-js adds only cross-platform features, not browser-only or server-only. I will add it if i will add modules for network and DOM.

[chicoxyzzy]

this makes sense.
thoughts: environment-specific features can be bundled as optional modules. than one will be able to import browser-shim.js or node-shim.js (or server-shim.js with respect to iojs). or is it sounds as a standalone project I better should start by myself?

[zloirock]

I'll think about it.

[zloirock]

@chicoxyzzy Think about what else can be added to the client and server shims.

[nelix]

It would be really nice to have core-js shim this function in both node and the browser.
All the current polyfill's either don't browserify nice or don't do commonjs (polluting window.fetch and Promise without permission).

[zloirock]

Because of the large number of requests, I reopen it. Maybe I will add it, but it's not priority task.

[nelix]

I'm not sure what I am getting my self into, but perhaps I could help out with this..? Since I care about it.

[zloirock]

Yep, you can add PR with implementation as modules/web.fetch.js. Module should be as compact as possible - library is already too bloated.

[NekR]

Why you need fetch people? It does not even have abort capabilities for request and will never be able to polyfill network streams such they as they will be present in fetch. All other functional is just wrap XHR with Promise.

[mgol]

I think core-js should continue to provide an ES6 environment, at least by default; fetch is a DOM standard so that would be vastly different. If you start polyfilling the DOM, the library will get much larger.

In any case, GitHub has a fetch polyfill that's fairly popular.

[steida]

Please don't add any DOM related stuff since it would break non DOM js enviroments.

[kevinbarabash]

It might make sense to have a separate core-dom report for DOM related polyfills. I say this after having requested NodeList[Symbol.iterator] be added a while back. I think the reason why people make requests here is that there doesn't seem to be a corresponding repo for polyfilling DOM stuff. There are a bunch of little repos that polyfill different DOM things, but people don't want to have to go find each of these individual repos.

[elliolir]

It's 2017 and still no updates regarding this. Yeah, it's not a big problem since fetch-polyfill is available, but imo it's more convenient to have one package installed rather that two.

[jonaskuske]

It'd be also much more convenient because then babel-polyfill could automatically polyfill fetch depending on your browserlist so you wouldn't have to add/remove the fetch polyfill depending on your target browsers...

[chicoxyzzy]

Actually babel-polyfill could do this using any other polyfill. Not sure that it should though but it's better to create such issue (if it doesn't exist yet) in Babel repo

[imprfekt]

It's 2018 and still no updates regarding this. Yeah, it's not a big problem since fetch-polyfill is available, but imo it's more convenient to have one package installed rather that two.

[loganfsmyth]

@precompiled I think the original logic still holds. The fetch API is not part of the ECMAScript spec, so it doesn't really make sense to have in this repository. For the same reason, it's also not something I'd expect to be part of @babel/polyfill. Babel's objective is to polyfill language-standard features. Adding this would be no different than if core-js tried to polyfill require('url') or require('path') modules, or MutationObserver or any number of other environment-specific APIs.

[chicoxyzzy]

@loganfsmyth BTW core-js already includes polyfills for non-ES things
https://github.com/zloirock/core-js#web-standards

[loganfsmyth]

That's true, but I also think the average dev considers setTimeout/setImmediate to be part of ECMAScript even while that may not technically be the case. I guess what I should say is that I'd consider the bar extremely high as far as cross-environment expectations go, and I don't think fetch meets those requirements.

[chicoxyzzy]

IMO developers expect that babel-polyfill will cover everything based on browserslist config. I see the reason why fetch is not in core-js, but considering that timeouts and DOM iterations are covered, missing fetch becomes non obvious issue.

[lake2]

same issue + 1

[Schweinepriester]

It's missing because currently core-js adds only cross-platform features, not browser-only or server-only.

fetch has now (experimentally) been added to node in nodejs/node@6ec2253.

• https://github.com/nodejs/node/blob/master/doc/changelogs/CHANGELOG_V17.md#2022-02-10-version-1750-current-ruyadorno
• Implement window.fetch into core nodejs/node#19393
• lib: add fetch nodejs/node#41749
• https://github.com/nodejs/undici#undicifetchinput-init-promise

[1593292349]

Expect this polyfills

[lekoaf]

Expect this polyfills

https://github.com/zloirock/core-js/blob/master/CONTRIBUTING.md

[Bessonov]

@1593292349 what is your use case? Otherwise I think the issue should be closed.