@apollo/utils.fetcher - npm Package Compare versions

Comparing version 2.0.0 to 2.0.1

dist/index.d.ts

		@@ -32,3 +32,3 @@ /// <reference types="node" />
		}
		export declare type Fetcher = (url: string, init?: FetcherRequestInit) => Promise<FetcherResponse>;
		export type Fetcher = (url: string, init?: FetcherRequestInit) => Promise<FetcherResponse>;
		//# sourceMappingURL=index.d.ts.map

package.json

		{
		"name": "@apollo/utils.fetcher",
		"version": "2.0.0",
		"version": "2.0.1",
		"description": "Minimal web-style fetch TypeScript typings",
		@@ -5,0 +5,0 @@ "main": "",

README.md

		@@ -9,4 +9,6 @@ # Fetcher interface

		Additionally, some `fetch` implementations accept various types for their request `body`; for example, `node-fetch` supports the use of `FormData` objects specifically from the `form-data` package. You may choose to use different types for your request `body`, so long as those types are supported by the `fetch` implementation of your choice. You will likely need to use a type assertion to convince TypeScript that your `body` is valid. Unfortunately, because different `fetch` implementations access different `FormData` classes, we weren't excited about the outcome of this [relevant PR](https://github.com/apollographql/apollo-utils/pull/225) and decided to undo it, but might be open to a simpler approach that solves the problem without the need for type assertions.

		Specifically, the `Fetcher` interface only declares options that are currently required by the software that uses it, such as Apollo Server and Apollo Gateway. If more options are required (and they are implemented with the same types in all `fetch` implementations), we can add them as needed.

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

dist/index.d.ts.map

Sorry, the diff of this file is not supported yet

New alerts