Any chance we'll see an update with the newer version of node-fetch? There has been some pretty significant work to bring node-fetch in line with spec.

The latest version of node-fetch is 1.6.0 would be great to get a release with that version.

The devDependency webpack was updated from 4.36.0 to 4.36.1.

🚨 View failing branch.

This version is covered by your current version range and after updating it in your project the build failed.

webpack is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Your Greenkeeper Bot 🌴

maybe I'm missing something, but these classes seem to be necessary to use fetch, and would depend on the ponyfilled implementation.

eg. see matthew-andrews/isomorphic-fetch@79e5368

☝️ Greenkeeper’s updated Terms of Service will come into effect on April 6th, 2018.

Version 2.0.14 of webpack-cli was just published.

This version is covered by your current version range and after updating it in your project the build failed.

webpack-cli is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Your Greenkeeper Bot 🌴

Version 10 of Node.js (code name Dubnium) has been released! 🎊

To see what happens to your code in Node.js 10, Greenkeeper has created a branch with the following changes:

• Added the new Node.js version to your .travis.yml

If you’re interested in upgrading this repo to Node.js 10, you can open a PR with these changes. Please note that this issue is just intended as a friendly reminder and the PR as a possible starting point for getting your code running on Node.js 10.

Your Greenkeeper Bot 🌴

Hi!

I'm trying to share code across a web app and Electron, and it's been working great on v4. However, when I try to upgrade this package in the Electron app from v4.1.0 to v5.0.0 (or later), all of the network calls silently stop working. v5 appears to still work in the web app with the exact same API code.

Has anyone else gotten version v5.0.0 or later to work with Electron?

Every support detection fails because self is set to an blank object:

https://github.com/github/fetch/blob/master/fetch.js#L9-L20

For example, using any of the supported body types such as FormData is currently not working.

The devDependency webpack was updated from 4.32.1 to 4.32.2.

🚨 View failing branch.

This version is covered by your current version range and after updating it in your project the build failed.

webpack is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Your Greenkeeper Bot 🌴

Thanks a lot for the ponyfill =)

Experience one issue on IE11 that crushes my app.

Have noticed that it fails with 'core-js' version above 3.5.0.
As for code investigation error appeared to raise at this expression to me preProcessedHeaders.split(/\r?\n/) .

Found same problem description in 'fetch' repo and PR with solution to it that worked fine in my case too.

Could you please apply this fix?

Note this isn't technically a problem with this package, but might ease some issues with Jetbrains IDEs, which don't seem to be picking up type definitions from fetch-ponyfill at the moment.

I would suggest adding the following line to package.json:

"types": "./index.d.ts"

See here:

https://intellij-support.jetbrains.com/hc/en-us/community/posts/115000071990-Does-intellij-IDEA-need-index-d-ts-to-import-from-package-

But you have to make sure that your index.ts file is specified in your 'common' module package.json as either "typings" or "types" value

https://www.typescriptlang.org/docs/handbook/declaration-files/publishing.html

if your main declaration file is named index.d.ts and lives at the root of the package (next to index.js) you do not need to mark the "types" property, though it is advisable to do so

Whenever I try to run

npm i fetch-ponyfill

I get

npm ERR! code ENOLOCAL npm ERR! Could not install from "node_modules/ms-rest-js/fetch-ponyfill@github:amarzavery/fetch-ponyfill#136e6f8192bdb2aa0b7983f0b3b4361c357be9db" as it does not contain a package.json file.

My mocha test is as follows:

/**
 * Test the request function
 */

import request from '../request';
import sinon from 'sinon';
import expect from 'expect';

describe('request', () => {
  // Before each test, stub the fetch function
  beforeEach(() => {
    sinon.stub(window, 'fetch');
  });

  // After each test, restore the fetch function
  afterEach(() => {
    window.fetch.restore();
  });

  describe('stubbing successful response', () => {
    // Before each test, pretend we got a successful response
    beforeEach(() => {
      const res = new Response('{"hello":"world"}', {
        status: 200,
        headers: {
          'Content-type': 'application/json',
        },
      });

      window.fetch.returns(Promise.resolve(res));
    });

    it('should format the response correctly', (done) => {
      request('/thisurliscorrect')
        .catch(done)
        .then((json) => {
          expect(json.data.hello).toEqual('world');
          done();
        });
    });
  });

But this results in:

  1) request stubbing successful response should format the response correctly:
     Error: timeout of 2000ms exceeded. Ensure the done() callback is being called in this test.

My test harness if you are interested:

import 'babel-polyfill';
import fetchPonyFill from 'fetch-ponyfill'; // module "whatwg-fetch" is browser-only
import jsdom from 'jsdom';
import chai from 'chai';
import chaiEnzyme from 'chai-enzyme';

chai.use(chaiEnzyme());

// setup the simplest document possible
const doc = jsdom.jsdom('<!doctype html><html><body></body></html>');

// get the window object out of the document
const win = doc.defaultView;

// set globals for mocha that make access to document and window feel
// natural in the test environment
global.document = doc;
global.window = win;
global.navigator = window.navigator;

// Fetch API
Object.assign(global, fetchPonyFill());

// Take all properties of the window object and also attach it to the
// mocha global object
// @see https://github.com/rstacruz/mocha-jsdom/blob/master/index.js#L80
function propagateToGlobal(window) {
  Object
    .keys(window)
    .forEach(key => {
      if ({}.hasOwnProperty.call(window, key)) {
        if (typeof global[key] === 'undefined') {
          global[key] = window[key];
        }
      }
    });
}


propagateToGlobal(window);

Any ideas why this might not be working?

I am trying to intercept the response for a token refresh implementation. Can anyone point to the right place?

Hello! I'm trying to use your module as part of a typescript project, but unfortunately it is missing a Typescript type declaration. I added the module like this to my code (I'm using webpack):

import { fetch } from "fetch-ponyfill";

But I'm getting the following error when trying to compile Typescript to JS:

(9,23): error TS7016: Could not find a declaration file for module 'fetch-ponyfill'. '/Users/simon.kreiser/Development/frontend/node_modules/fetch-ponyfill/fetch-node.js' implicitly has an 'any' type.

Would you be interested in adding Typescript support? I'd be willing to help out or contribute. I'm relatively new to typescript, but I found this tutorial on how to write d.ts. files: https://blogs.msdn.microsoft.com/typescript/2016/12/14/writing-dts-files-for-types/

Should be pretty simple, and avoids needing to generate the wrapper at runtime.

Hey there. I'm using fetch-ponyfill 1.0.0 with node-fetch 1.5.1
When I try to run my tests, I get this error:
TypeError: Fetch.Promise is not a function

I looked into the source of node-fetch, and they recently added the notion of the Fetch class, which requires Promise to be an attribute of Fetch. The current implementation of fetch-ponyfill only applies this to fetch (lowercase). Want a PR for it?

I've taken a couple steps to promote this library, e.g. matthew-andrews/isomorphic-fetch#93

This is an elegant, safe, and effective solution to a common problem, one really worth promoting. With the recent changes, I think its scope has changed. It's not just a browser ponyfill, it's also an isomorphic fetch. What do you think about updating the description to reflect that?

isomorphic-fetch describes itself like this:

Isomorphic WHATWG Fetch API, for Node & Browserify

I think what we've got here is:

Isomorphic WHATWG Fetch API ponyfill for Node, Browserify, and Webpack

For people to find this, I think the most effective thing would be to update the github name and npm description along those lines. The second thing would be to mention Browserify and Webpack in npm keywords and in the body of the readme.

Thoughts?

fetch-ponyfill always acts as a wrapper for XHR in the browser, but better to use native fetch if it's available. Seems like these lines always forces to use polyfill, why are they needed?

☝️ Greenkeeper’s updated Terms of Service will come into effect on April 6th, 2018.

Version 4.4.7 of sinon was just published.

This version is covered by your current version range and after updating it in your project the build failed.

sinon is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Your Greenkeeper Bot 🌴

I am hoping to have access to the RequestInit type when using a cross-environment fetch solution like this or https://www.npmjs.com/package/portable-fetch. Is that something that has ever been considered? Am I missing something?

The last entry on the history.md is about 3.0.2.

Package minimist had Prototype pollution bug in versions previous to v1.2.3: https://github.com/substack/minimist

mkdirp 0.5.1 is having a dependency on minimist.
Please update your package to include a new version of mkdirp (maintained by @isaacs/node-mkdirp) or if you follow ESLint, remove mkdirp completely.

Have you thought about adding support also for aborting the reqeusts? ( https://developer.mozilla.org/en-US/docs/Web/API/AbortController/abort )

On browser environment, we could use have a ponyfill similar to this polyfill: https://github.com/mo/abortcontroller-polyfill .

On node environment, node-fetch seems to already support AbortController: node-fetch/node-fetch#95 .

So this fetch-ponyfill could also ponyfill the abortcontroller, and export AbortController and AbortSignal. WDYT?

It would be great if releases had the the very least a TL;DR. Going through the commits from one version to the next obviously provides all of the necessary details, but it would be nice to have a summary

The title may seem a little off, but the problem I found is that importing fetch-ponyfill multiple times run the bootstrapper for each of those imports.

// module-one.js
import fetchPony from 'fetch-ponyfill'
const { Headers } = fetchPony()

// module-two.js
import fetchPony from 'fetch-ponyfill'
const { Headers } = fetchPony()

Something like above will create two equal, but not the same Headers classes. This makes it impossible to create one headers in stance from the other because it is no recognized by the instanceof check which whatwg-fetch does

Try this sandbox: https://codesandbox.io/s/fervent-fermi-5iews?file=/src/index.js

I've got a proof of concept of a version of this which does not depend on brfs and is also agnostic of webpack. I adapted the clever approach you took here, of patching whatwg-fetch without vendoring in the source. But instead of doing it at compile time, I did that in a build step, and checked in the result.

It's a little bit gross to check in the generated code, but I like that it's a bundler-agnostic solution. Agnosticism is a good thing. An ecosystem of opinionated packages leads to JavaScript fatigue, which is something I'm feeling pretty heavily these days.

To me, checking in a generated CommonJS module seems like a reasonable compromise for bundler agnosticism, though I'm curious your thoughts.

I need a Node + Webpack ponyfill for my current project, but I haven't found one of those – hence building this POC – and I'd rather use something that is Browserify-compatible too. My team is trying out webpack, mostly for hot loading, but hasn't really settled on it in the long term. I know there are some hot-loading solutions for Browserify now. Really, just trying to stay agnostic.

Would you be interested in taking a look at it and seeing if you'd like to incorporate it into this project? If you'd like to incorporate it here, I can avoid publishing a new project (and adding marginally to everyone else's JS fatigue). If not, I certainly have no problem publishing it separately.

Version 4.10.1 of webpack was just published.

This version is covered by your current version range and after updating it in your project the build failed.

webpack is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Your Greenkeeper Bot 🌴

fetch-ponyfill has a direct dependency on an old version of "node-fetch": "~2.6.1", which in turn depends on an old version of "whatwg-url": "^5.0.0", which uses Node's long deprecated punycode module (https://nodejs.org/api/punycode.html). As of Node 21, this is now causing Node to generate warning messages every time it is run:

(node:12764) [DEP0040] DeprecationWarning: The `punycode` module is deprecated. Please use a userland alternative instead.

This could be fixed, I think, by bumping your node-fetch dependency to the current v3 (https://github.com/node-fetch/node-fetch/), which no longer depends on whatwg-url. (Although I will also note that the latest version of whatwg-url is free of punycode as well).

I love this package. I use it with Browserify to ship code for an embeddable component, which developers can embed into their web pages, and appreciate that it doesn't manipulate globals to do its work.

Now I'm working on another project, and I'm having trouble. I'm writing an HTTP client, using fetch, which I want to ship via Browserify, and also test outside the browser, using mocha and node.

isomorphic-fetch has a solution for this, which appears to use the browser keyword in package.json. In the node environment, it polyfills global.fetch with node-fetch. I haven't tested it myself, but it seems to work.

Of course, I don't want a polyfill.

So my question is, would you be interested in adding support for this use case – code which needs to run both in Browserify and Node? If you are, I'd be happy to work up a PR.

The devDependency promise was updated from 8.0.2 to 8.0.3.

🚨 View failing branch.

This version is covered by your current version range and after updating it in your project the build failed.

promise is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Your Greenkeeper Bot 🌴

Currently there is an outstanding issue with webpack and node-fetch:

node-fetch/node-fetch#450

The suggested workaround is var fetch = require("node-fetch").default; instead of just var fetch = require('node-fetch')

Also saw this was mentioned in #227 and #192

My specific reason for this issue is because it is required to use webpack for netlify lambda functions and a couple libraries I rely on are upstream dependents.

Version 4.1.6 of sinon was just published.

This version is covered by your current version range and after updating it in your project the build failed.

sinon is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Your Greenkeeper Bot 🌴

I love this library. It helps me build isomorphic javascript clients without polluting the global space. Thanks for the good work.

I wanted to use cookies for node-fetch in some of the scenarios. There is a package named fetch-cookie that works well with node-fetch.
It would be nice if this can be exposed via options: { useCookie : true|false }.
if the user needs cookie support then in fetch-node.js we could wrap node-fetch inside fetch-cookie, otherwise it would be business as usual.

'use strict';

var fetch = require('node-fetch');

function wrapFetchForNode(fetch) {
  // Support schemaless URIs on the server for parity with the browser.
  // https://github.com/matthew-andrews/isomorphic-fetch/pull/10
  return function (u, options) {
    if (fetch && fetch.Request && u instanceof fetch.Request) { //<<<<<<<<<<<<<<<<<<<<<<<<<<
      return fetch(u, options);
    }

    var url = u.slice(0, 2) === '//' ? 'https:' + u : u;

    return fetch(url, options);
  };
}

module.exports = function (context) {
  // This modifies the global `node-fetch` object, which isn't great, since
  // different callers to `fetch-ponyfill` which pass a different Promise
  // implementation would each expect to have their implementation used. But,
  // given the way `node-fetch` is implemented, this is the only way to make
  // it work at all.
  if (context) {
    if (context.Promise) {
      fetch.Promise = context.Promise;
    }
    if (context.useCookie) {
      fetch = require('fetch-cookie')(fetch); //<<<<<<<<<<<<<<<<<<
    }
  }

  return {
    fetch: wrapFetchForNode(fetch),
    Headers: fetch.Headers,
    Request: fetch.Request,
    Response: fetch.Response
  };
};

The variable "self" is declared on line 10, however, it is being used before that on lines 5-6. My test runner is throwing an error because of this. Can we not move it further up?