Avoid import when targets support native fetch

[rwjblue]

We can use this.project.targets to determine if the whatg-fetch polyfill is required for the browser builds, and avoid app.importing it when it is not needed.

See browser support. Roughly includes all evergreen browsers (FireFox, Edge, Chrome, Safari)...

[cibernox]

I agree, but there was some fear for two things:

• Possible edge cases in which the polyfill doesn't behave perfectly
• The problem that pretender.js will not work with fetch, and it is VERY popular. We need pretender-fetch to happen.

[rwjblue]

Possible edge cases in which the polyfill doesn't behave perfectly

I'm not sure what you mean here.

The problem that pretender.js will not work with fetch, and it is VERY popular. We need pretender-fetch to happen.

I believe that someone was working on this already, do you recall that?

[cibernox]

I'm not sure what you mean here.

I mean that @stefanpenner was concerned that perhaps people in development had modern targets and things work but when they deploy to prod, with the polyfill, something is different in some subtle way. I don't buy that argument a lot tho.

I believe that someone was working on this already, do you recall that?

I recall, it was me 🤣 . I really need to come back to that.

[kratiahuja]

I am curious to understand why fetch will not work with pretender? Pretender just replaces the XHR layer with Fake XHR AFAIU. If fetch (with the polyfill) is calling XHR under the hood, you don't need a pretender-fetch. Example: if you use jQuery.ajax pretender doesn't do anything special.

[rwjblue]

If fetch (with the polyfill) is calling XHR under the hood, you don't need a pretender-fetch.

The goal of this issue is to avoid including the polyfill at all, when the browsers that the application supports already have native fetch.

[kratiahuja]

Agreed, my question is more around to understand why pretender will not work with fetch in testing (if your tests are already running against browsers that support fetch)? pretender should be agnostic to the high-level network interface being used (whether fetch/jQuery.ajax) etc.

[rwjblue]

Pretender currently only captures requests that go through XHR. When native fetch is used its requests will no longer funnel through XHR and therefore Pretender will not be able to intercept. @cibernox has a spike for a "fake fetch" (akin to FakeXHR which pretender uses now), which should address this concern (though I actually do not consider it a blocker).

[xg-wang]

@rwjblue Sorry I didn't notice the issue. Seems there's still no update on pretender fetch, but it's already 2 years from that issue. I was wondering whould we begin to provide an option to use native fetch.

[xg-wang]

This is supported after v5.1.0 #63

[mydea]

Just out of curiosity, is the polyfill still included in the vendor file at all time, correct?
Wouldn't it be nice to not even include it, if all browser targets have it?

[rwjblue]

@mydea - Yes, totally agreed.

@xg-wang - This issue was created to track avoiding the include the polyfill at all in vendor.js, but AFAICT the fix added in #63 will still continue to ship the polyfill but will avoid using it if native fetch is present. I'm reopening this issue so that we can track the vendor.js "slim down"...

[xg-wang]

Released as v6.4.0 🎉

As mentioned in readme, to avoid bundling redundant polyfill assets just set preferNative to true

// ember-cli-build.js
let app = new EmberAddon(defaults, {
  // Add options here
  'ember-fetch': {
    preferNative: true
  }
});

Browser targets supports for fetch and abortcontroller are checked from caniuse-api. ember-fetch will then load only the necessary polyfills and its own wrapper 😄

Thanks @mydea for landing this feature!