See logs:

> now-rm@ start /usr/src/app
> micro -p 3000 .

micro: Error when importing /usr/src/app: Error: Cannot find module '@zeit/fetch-retry'
    at Function.Module._resolveFilename (module.js:527:15)
    at Function.Module._load (module.js:476:23)
    at Module.require (module.js:568:17)
    at require (internal/module.js:11:18)
    at Object.<anonymous> (/usr/src/app/node_modules/@zeit/fetch/index.js:1:87)
    at Module._compile (module.js:624:30)
    at Object.Module._extensions..js (module.js:635:10)
    at Module.load (module.js:545:32)
    at tryModuleLoad (module.js:508:12)
    at Function.Module._load (module.js:500:3)
micro: https://err.sh/micro/invalid-entry

This happens when I run this on k8s.

Found this bug while working with transitive-bullshit/react-static-tweets#43 and posted a gnarly post-install work-around over there.

The issue happens when doing a GET call on some endpoints, mine specifically being https://syndication.twitter.com/tweets.json?ids=296658470705438720.

I've confirmed with local calls in a (very friendly) loop to https://syndication.twitter.com/tweets.json?ids=296658470705438720 that that endpoint isn't intermittently returning 404. Actually, on the application instance, once a single 404 is returned it continues to return 404s which might indicate a state-related issue within vercel/fetch.

This is the line that causes the issue 404 in the aforementioned repo:
https://github.com/transitive-bullshit/react-static-tweets/blob/4ff2e4e6eb138c3a98f364beb0117f0e2d5acc90/packages/static-tweets/src/twitter/api.ts#L16

I'll post more information / PR if I find anything helpful.

🚨 You need to enable Continuous Integration on all branches of this repository. 🚨

To enable Greenkeeper, you need to make sure that a commit status is reported on all branches. This is required by Greenkeeper because it uses your CI build statuses to figure out when to notify you about breaking changes.

Since we didn’t receive a CI status on the greenkeeper/initial branch, it’s possible that you don’t have CI set up yet. We recommend using Travis CI, but Greenkeeper will work with every other CI service as well.

If you have already set up a CI for this repository, you might need to check how it’s configured. Make sure it is set to run on all new branches. If you don’t want it to run on absolutely every branch, you can whitelist branches starting with greenkeeper/.

Once you have installed and configured CI on this repository correctly, you’ll need to re-trigger Greenkeeper’s initial pull request. To do this, please delete the greenkeeper/initial branch in this repository, and then remove and re-add this repository to the Greenkeeper App’s white list on Github. You'll find this list on your repo or organization’s settings page, under Installed GitHub Apps.

Right now it's not clear than you can just do require('@zeit/fetch')() and that require('@zeit/fetch')(require('node-fetch')) isn't necessary.

The readme should explain this a little better.

If the package is used in a javascript project, a warning is thrown:

warning " > @vercel/[email protected]" has unmet peer dependency "@types/node-fetch@2".

If this was moved to dev dependencies, it would stop that error from showing up I believe. Also, we could probably move @types/async-retry down to dev dependencies too while we're at it.

Would there be any problems I'm not foreseeing if I made this change?

Hello,

thanks for providing this handy fetch replacement.

I wanted to provide feedback based on our usage of the lib. We were recently surprised to discover, that fetch-retry also retries non-idempotent and non-safe http requests (see the http spec section 9.2). This can lead to unintended effects on the target server.

I would suggest, that by default, fetch-retry should only retry idempotent or safe methods as defined by the spec, and optionally provide a setting, so that all methods are retried. In order to avoid a breaking change, it would also be viable to leave the default as is, and explain in the docs, how the spec compliant behaviour can be setup.

I would be open to contribute if we can agree on a solution.

Right now it's 200, which is good for many use cases, but overkill for others. As an example, if you write a little utility that abstracts over fetch, and someone uses it as a module, they get a 200 socket pool by default.

A more reasonable default would be 50

while we passed FormData in server side , it will run into these code,

opts.body = JSON.stringify(opts.body);
opts.headers.set('Content-Type', 'application/json');
opts.headers.set('Content-Length', Buffer.byteLength(opts.body));

But for form-data in server side, maybe sometimes we need to passfs.createReadStream as form-data

it should not set header 'Content-Type', 'application/json'

Looks like multipart requests (like POST with Image) are not working.
Multipart requests with FormData body are not supported by the library, I see only string and Buffer are.

Should we do something similar to Buffer for FormData here? https://github.com/zeit/fetch/blob/master/index.js#L50

https://github.com/zeit/dns-cached-resolve/ defaults to 300s, which could be problematic with records with lower ttls. For example, AWS ELBs always use 60s.

This would require a change to https://github.com/zeit/fetch-cached-dns/ as well, I believe.

I can't get this module to work, because

import fetch from '@vercel/fetch';

Is incorrect

{
  message: "fetch() argument isn't a function; did you forget to initialize your `@vercel/fetch` import?",
  code: -32603,
  data: {
    code: 'INTERNAL_SERVER_ERROR',
    httpStatus: 500,
    path: 'krakenRouter.sendError'
  }
}

There is no complete example here.

https://github.com/zeit/fetch/blob/53ee6c5bf02a5dd261a6ce4df0f687fa32c2b4d1/index.js#L57-L59

It should only create one agent per protocol.

I am using the https://nextjs.org/commerce and a line within that is attempting the following

import type { RequestInit } from '@vercel/fetch'
Which is not a named export from this library.

In my package.json it says I have version
"@vercel/fetch": "^6.1.0",
Which is the most recent one. Is this export still available in the latest version of the library?

I think the current one is too high (socket timeout I believe). I think maybe 5s would be a good timeout?

We are facing an issue when migrating from node-fetch to @zeit/fetch due to the fact that some of the properties in provided opts object are mutated before calling the decorated fetch function.

We are having issues mainly with headers, but I see the body is overwritten too.

Maybe it would be a good idea to copy provided opts and mutate the copy before passing to the wrapped fetch instead? It would remove these unexpected side effects.

I think I could try to provide the fix if you are ok with it.

For example, 501 is not.

We will be archiving this repository in favor of fetch in Node.js. Existing versions will not be deprecated and can be continued to be used. This project has worked well, but with the latest options from Node.js, we believe it’s now sufficient to replace this library.

The native Fetch within Node.js (vendored from Undici) is more spec-compliant than the default node-fetch this library ships. Plus, it utilizes a keep-alive agent by default. Retry logic is coming soon and other libraries exist to fill this need if you are looking to implement it yourself (such as async-retry).

Thank you to all the community contributions!

Ex:

const fetch = require('@zeit/fetch')(require('node-fetch'))
const url = 'https://github.com/paulkernfeld/node-headless/tarball/master'

async function main() {
  const res = await fetch(url, {
    headers: {
      'User-Agent': 'ace'
    }
  })
  console.log(res)
}

main().catch(err => {
  console.error(err);
  process.exit(1);
});

Hello,

I'm trying to use @vercel/fetch in nextjs on the serverside
Whatever I try I always have the same error:

./node_modules/@zeit/dns-cached-resolve/lib/dns-resolve.js:6:0
Module not found: Can't resolve 'dns'

Am I doing something wrong?

Thanks for your help.

Vanilla fetch supports passing a Request object as its first parameter. This works really great for flows that incrementally build out a Request object to then pass to fetch.

This API is also supported in node-fetch, which exports a Request implementation in its package. But when wrapping node-fetch with @vercel/fetch, and passing a Request object, an error is thrown: The "url" argument must be of type string. Received an instance of Request. This means none of our flows that worked with node-fetch and vanilla fetch will work with @vercel/fetch.

Is there any intention on supporting passing a Request object, as is described in the fetch spec?

I am using Craft Nitro (https://getnitro.sh/) for local CMS development and connecting to the api using @vercel/fetch. Nitro provides URL's that look like https://testcms.nitro and updates the /ect/hosts file with that domain. However these domains do not resolve using @vercel/vetch

It looks like this is happening because https://github.com/vercel/dns-cached-resolve is using dns.resolve4/dns.resolve6 both of which ignore the hosts file. Looking into the node DNS documentation it looks like dns.lookup uses the system DNS lookup which does look at /etc/hosts however there are performance implications when using it (https://nodejs.org/api/dns.html#implementation-considerations)

https://github.com/vercel/dns-cached-resolve special cases localhost, but It might be a good idea to allow a fallback to dns.lookup when dns.resolve fails to allow other domains defined in /etc/hosts to work. This could be an option set when setting up @vercel/fetch and it would allow enabling / disabling this behaviour depending on environment.

I don't know why jest is so fast at quitting if sockets should be remaining open with the introduction of agentkeepalive