fetch: Fetch breaks with update to 3.0.0

It seems, that after updating the build to rollup, the code is not transpiled correctly for IE11. We are recieving this error.

SCRIPT1002: Wrong syntax
File: fetch-polyfill.js, row: 87, column: 1

The fetch-polyfill.js includes the fetch.js file from your repository.

This is where it fails:

export function Headers(headers) { // row 87
  this.map = {}

  if (headers instanceof Headers) {
    headers.forEach(function(value, name) {
      this.append(name, value)
    }, this)
  } else if (Array.isArray(headers)) {
    headers.forEach(function(header) {
      this.append(header[0], header[1])
    }, this)
  } else if (headers) {
    Object.getOwnPropertyNames(headers).forEach(function(name) {
      this.append(name, headers[name])
    }, this)
  }
}

export function syntax is not supported in IE11

Version: 3.0.0 OS: Linux, Windows

Version 2.0.4 works fine for us.

About this issue

  • Original URL
  • State: closed
  • Created 6 years ago
  • Reactions: 2
  • Comments: 23 (4 by maintainers)

Commits related to this issue

Most upvoted comments

Yes, fetch.js file now has the ES6 export syntax and will not be compatible with many browsers. This is why we build the UMD dist file and point to it from this package’s main property, while the module property points to fetch.js.

The solution is to respect the main property from this package instead of loading the fetch.js file directly. The file reorganization and UMD introduction was the main reason for the major version bump to v3.

With the new release, it looks like you need to pull the umd version from the dist folder.

Here’s one possible way:

<script src=https://cdn.jsdelivr.net/npm/promise-polyfill@8.1/dist/polyfill.min.js></script>
<script src=https://cdn.jsdelivr.net/npm/whatwg-fetch@3.0/dist/fetch.umd.min.js></script>

(Also this does seem an odd choice for a polyfill. Do any browsers actually exist that need a fetch polyfill and can do ES6? I don’t understand what targets or use-cases an ES6 fetch polyfill is serving, but that just may be my lack of contemporary JS expertise. For me, not being an expert, it makes it somewhat more complicated to figure out how to properly deliver this polyfill to browsers that actually need it.)

How can this be used correctly via a CDN?

@jakob-e For sure; if I knew how many cascading failures would the 3.0 release cause, I would have done this more carefully. 😣 However, I still don’t believe that our team is responsible for actually fixing most of those failures. Too many people and scripts have hardcoded loading the whatwg-fetch/fetch.js file in their apps instead of parsing the whatwg-fetch/package.json properly, and they will have to either:

  1. Fix their scripts/processes; or
  2. Avoid upgrading to a major version of a library they’re not ready for yet. When it comes to semver, "Major" literally means “breaking changes”, if anyone was still unclear about this!

As for the CDN problem, here is what we (the maintainer team) don’t have to do to fix it:

  1. We don’t have to remove any export statements. We ship an ES module with our package now, and removing those exports would break the module.
  2. We don’t have to to do literally anything else to un-break the CDNs, since we didn’t publish nor maintain whatwg-fetch on any CDN in the first place. That was all a community effort, and it’s beyond our control.

What CDNs should do to fix this:

  • Parse the package.json of whatwg-fetch to determine the file referenced by the main property, and serve that to browsers.

I’m closing this now because there’s not anything actionable for us to do to address the issues people have been having in this thread. If I have missed something, please let me know!

Is fetch.umd.js file supposed to be on the bower package ? Because it is not…