Node.js support

[kirill-konshin]

Do you have anything in your roadmap regarding Node.js support?

The purpose is to allow other cross-env libraries to use fetch as the client.

From what I see now in master there are couple of things to be done:

1. Use XMLHttpRequest polyfill (for example https://github.com/pwnall/node-xhr2)
2. Wrap the code in something like UMD to make sure CommonJS and AMD compatibility
3. Export all classes and fetch() function instead of always writing to global
4. Add optional polyfill() method just like in es6-promise for AMD users
5. Take over NPM package name fetch, current one is unmaintained for 2 years

Is it worth investigation and making a PR? Does not seem to be too much effort.

[matthew-andrews]

@kirill-konshin have you seen the node-fetch project? If you want a single library that will pull both through you might even like to consider using mine as well.

[kirill-konshin]

Github's polyfill is the most popular and well known, so I thought maybe it is reasonable to make it isomorphic...

I personally prefer single library approach so that I won't have to deal with bugs in 2-3 libraries which potentially may not catch up with the spec/bleeding edge implementations :)

Your version is not UMD-wrapped (will not work with RequireJS at all) and it is not a one-file dependency as this repo (yours has own sub-dependencies, which means slightly trickier install for non-AMD users and front end developers in general).

As I said earlier, those 5 items does not seem to be hard to do.

[matthew-andrews]

You make some really good points that I hadn't thought about before because I don't really use RequireJS.

I remember point 5 was considered but rejected because in order not to break backwards compatibility this repo would have to jump to v2.0.0… which didn't make sense… Once you know it's whatwg-fetch though it's not too difficult to find, is it?

I can't speak for the GitHub team but much of what you're asking for seems to take this project away from what I think it is defined as:- a client side implementation of the whatwg fetch specification and nothing more.

I don't think it would be very difficult to make a little requirejs-isomorphic-fetch wrapper similar to my one (perhaps mine ought to have been called commonjs-isomorphic-fetch). Maybe you could do it? :)

Also having used variants of fetch on the server for over half a year in production (including initially one that used the node XMLHttpRequest polyfill, which is abandoned too*) I really must recommend node-fetch. It is far far far more robust and is actively maintained!

* Here's a pull request I made to it in January.

[kirill-konshin]

I was talking about https://github.com/pwnall/node-xhr2 which I've been using in production for about a year too :) but anyway, native NodeJS http(s) modules will do a much better job.

If another isomorphic library uses fetch for browser (even wrapped in order to be compatible with AMD/Browserify/Webpack) and node-fetch for NodeJS then it 100% leads to trickery around package names in UMD definition which leads to issues with Browserify/Webpack (they tend to try to resolve both packages). I had such issues in the past, maybe it's not true anymore, I will check it.

I think we've got 2 options:

1. Only wrap fetch in UMD declaration in order to make it compatible with AMD/Browserify/Webpack (items 2, 3, 4 in my first list)
2. First option + use NodeJS http and https

Since they are sequential, I can make a PR for option 1 and then take a look on option 2.

[kirill-konshin]

I think that it's OK to deviate a bit from the original course in order to make someone's life easier :)

[mislav]

Hi, the request to make this library isomorphic comes in every now and then and we always refuse it. You should have searched past issues, like: #31 (comment)

To reiterate our reasons for refusal:

1. The goal of this library is to create a polyfill for an upcoming web browser standard.
2. We're not aware that there's any attempt to standardize fetch with the same API within Node.js.
3. We don't use this library on the server and therefore there's no incentive for us to maintain isomorphic support.
4. There are alternative libraries for fetch in Node environment that probably do a better job of maintaining that functionality than we would have done.

[kirill-konshin]

Ok, than what about at least making it AMD-compatible? So that I can use the same interface like:

var {fetch, Request, Headers, Response} = (typeof window !== 'undefined') 
    ? require('fetch') 
    : require('node-fetch');

Right now fetch polyfill only patches the global scope and does not export anything.

[kirill-konshin]

Taking into account that currently in Chrome there is no way to track fetch requests in network tab, I would like to use polyfill even if native implementation is available. Which can be achieved with appropriate exports or polyfill() method.

[dgraham]

Chrome's Network tab displays all requests, including those made with window.fetch. You can force the polyfill by removing the browser's native implementation before loading the fetch.js file.

<script>window.fetch = null</script>
<script src="fetch.js"></script>

I don't recommend doing this, but it will work.

[dgraham]

Right now fetch polyfill only patches the global scope and does not export anything.

The Fetch specification defines window as implementing the fetch method. There is nothing to export because fetch is not defined as a module that may be imported.

Our goal is to faithfully implement the polyfill in accordance with the specification so that it interoperates well with browsers' native fetch implementations.

[kirill-konshin]

Sorry for slightly wrong description, here is what I meant: https://code.google.com/p/chromium/issues/detail?id=457484, Chrome does not show POST bodies as it does for XHR.

The solution with deleting window.fetch was first thing that came into my mind too :) unfortunately, it will make a global change which should be avoided.

As an example, https://github.com/jakearchibald/es6-promise is an AMD compatible module, which can be loaded in scope and will not poison the global scope if not asked to do so.

[mislav]

@kirill-konshin You can easily obtain a reference to this fetch under another name.

<script>
originalFetch = window.fetch
window.fetch = null
</script>
<script src="fetch.js"></script>
<script>
realPolyfillFetch9000 = window.fetch
window.fetch = originalFetch
</script>

We're not responsible for the Chrome inspector bug and we will not change our code to work around your debbuging troubles. Charles Proxy is a great HTTP debugging tool that works regardless of browser inspector support.

[kirill-konshin]

I am using Charles all the time.

All that you said does not mean that you can't take the approach of es6-promose though. Not because of my "debbuging troubles" but for the sake of better implementation and integration. Don't you think so? Mangling with window does not seem to be a good solution if fetch is used in AMD environment where such trickery is not needed at all.

[mislav]

We don't want to maintain modular support for fetch right now because we don't want to support people loading it in a modular fashion just yet (or never).