		{
		"name": "@apollo/utils.fetcher",
		"version": "1.0.0",
		"version": "1.1.0",
		"description": "Minimal web-style fetch TypeScript typings",
		@@ -9,3 +9,3 @@ "types": "dist/index.d.ts",
		"url": "git+https://github.com/apollographql/apollo-utils.git",
		"directory": "fetcher/"
		"directory": "packages/fetcher/"
		},
		@@ -19,6 +19,3 @@ "keywords": [
		"author": "Apollo <packages@apollographql.com>",
		"license": "MIT",
		"publishConfig": {
		"access": "public"
		}
		"license": "MIT"
		}

README.md

		@@ -5,3 +5,3 @@ # Fetcher interface

		The goal is for software that wants to be able to make HTTP requests in a configurable fashion to be able to declare an option of this type; users can pass in any valid `fetch` implementation such as `node-fetch` or `make-fetch-happen`.
		The goal is for software that wants to be able to make HTTP requests in a configurable fashion to be able to declare an option of this type; users can pass in any valid `fetch` implementation such as `node-fetch`, `make-fetch-happen`, or `undici`.

		@@ -12,2 +12,2 @@ The actual `fetch` API is very flexible. You can specify requests either as JSON-style objects or as objects of the `Request` and `Headers` classes. However, some `fetch` implementations distinguish between these cases by using (for example) `instanceof Headers`, where `Headers` is the particular class defined by that implementation. So if you want to write portable code that should work with any `fetch` implementation, you need to use JSON-style objects rather than a particular implementation's classes. (For example, a `Headers` object created with `node-fetch` v2 will not be properly recognized by `make-fetch-happen` v10.)

		This package is validated to be compatible with the typings of `node-fetch` v2 and `make-fetch-happen` v10.
		This package is validated to be compatible with the typings of `node-fetch` v2, `make-fetch-happen` v10, and `undici` v5.

src/__tests__/index.test.ts

		import type { Fetcher } from "..";
		import nodeFetch from "node-fetch";
		import makeFetchHappen from "make-fetch-happen";
		import { fetch as undiciFetch } from "undici";

		@@ -15,1 +16,5 @@ // This "test suite" actually does all its work at compile time.
		});

		it("undici is a Fetcher", () => {
		isAFetcher(undiciFetch);
		});

src/index.ts

		@@ -9,2 +9,36 @@ export interface FetcherRequestInit {

		// A provided `signal` should be an object created by a class named
		// `AbortSignal` (the constructor name is checked by some implementations like
		// node-fetch and make-fetch-happen!) which follows the DOM AbortSignal API.
		// Notably, it should have `aborted: boolean` and methods `addEventListener`
		// and `removeEventListener`. We do not provide a precise interface for it
		// because we have found that runtime implementations are more consistent than
		// TypeScript definitions; for example, the methods such as addEventListener
		// end up being defined in terms of complex DOM types which vary by
		// implementation.
		//
		// Note that a relatively recent addition to the spec
		// (https://github.com/whatwg/dom/pull/1027) is the concept of an abort
		// reason. None of the polyfill Node AbortController/AbortSignal
		// implementations seems to support this yet (though Node's built-in
		// implementation does as of v18). It is possible that some Fetch
		// implementations might rely on the existence of this new functionality, say
		// by calling signal.throwIfAborted(). If so, you would need to use an
		// AbortSignal that supports this (such as the Node v18 implementation). As of
		// now, it does not appear that node-fetch, make-fetch-happen, or undici rely
		// on throwIfAborted, although undici does look at signal.reason if it is
		// provided.
		//
		// The main motivation for providing this as `any` (rather than, say, an
		// interface where the functions take `any` arguments to avoid linking in DOM)
		// is because if we leave out the newer `reason`/`throwIfAborted` fields, then
		// implementations like undici that use the Node v18 definitions won't
		// typecheck, but if we include those fields, then `AbortSignal`s from
		// `AbortController` polyfill libraries such as `node-abort-controller` won't
		// typecheck because they don't provide those fields. While in a sense that's
		// correct, we don't want to provide an interface for which there are no
		// existing implementations for Node v16 or older! (We may later choose to
		// publish our own polyfill and make this type more exact.)
		signal?: any;

		// We explicitly do not support non-portable options like `node-fetch`'s
		@@ -11,0 +45,0 @@ // `agent`.

dist/index.d.ts.map

Sorry, the diff of this file is not supported yet

@apollo/utils.fetcher - npm Package Compare versions

New alerts

Fixed alerts

Improved metrics