Add runtime dependency on node-fetch

[benweatherman]

We use node-fetch during runtime for some of the public methods in RemoteGraphQLDataSource. Using node-fetch@2 because v3 is ESM-only. There's already a renovate rule to keep things from going to v3.

We should probably break the interfaces that are using node-fetch's classes, since they aren't used by the default implementation after switching to make-fetch-happen.

Other detritus

• Remove @types/node-fetch This was originally included in Add production dependency on @types/node-fetch. apollo-server#3546 as a fix for @apollo/gateway doesn't include node-fetch in its dependencies apollo-server#3471.
• Change some imports to use type so there's no runtime dependency for things that are just using types.
• Remove pretty-format since that's not a runtime thing

Fixes #1961

TODO

• Investigate using plain-ol-javascript-object headers instead of Headers object
• Add CHANGELOG entry

[netlify]

✅ Deploy Preview for apollo-federation-docs canceled.

Name	Link
🔨 Latest commit	cf1046d
🔍 Latest deploy log	https://app.netlify.com/sites/apollo-federation-docs/deploys/62d5e29073a04a0008a8ae7f

[codesandbox-ci]

This pull request is automatically built and testable in CodeSandbox.

To see build info of the built libraries, click here or the icon next to each commit SHA.

[abernix]

Agree the dependency appears to be required currently because we literally use new Headers to pass in the headers to the fetch implementation.

That said, am curious if we could opt to just pass a plain object as headers rather than a Headers. It's my understanding that most fetch implementations will accept merely an object, and the Fetch API specification suggests that it's completely fine to do so. Is that worth a consideration?

Anyhow, just a thought. LGTM, but also like the idea of not including the dependency at all if we can avoid it.

[benweatherman]

curious if we could opt to just pass a plain object as headers

I like this line of thinking and I tried but got hung up on some type conflicts that were buried a bit too far. Lemme dig those up so we can talk specifics, instead of this hand-wavy response I've got so far.

[benweatherman]

appears to be required currently because we literally use new Headers to pass in the headers

I missed this part of the comment earlier. We also use new NodeFetchRequest to pass to some callbacks like thus (so I think we'd have to break that interface to start supporting a more generic Request, since NodeFetch has things like agent, etc)

federation/gateway-js/src/datasources/RemoteGraphQLDataSource.ts

Lines 196 to 201 in 8c4ecd6

	// Note that we don't actually send this Request object to the fetcher; it
	// is merely sent to methods on this object that might be overridden by users.
	// We are careful to only send data to the overridable fetcher function that uses
	// plain JS objects --- some fetch implementations don't know how to handle
	// Request or Headers objects created by other fetch implementations.
	const fetchRequest = new NodeFetchRequest(http.url, requestInit);

So even if we get rid of new Headers, we'll still have that interface to support.

That said...

We use this type declaration for headers for all of our GraphQLRequests, which provides a lot more methods than a plain-ol-javascript-object. https://github.com/apollographql/apollo-server/blob/3e0b6f917588052d179811fac366889056b34073/packages/apollo-server-env/src/fetch.d.ts#L13-L26. So we'd have to break the GraphQLRequest interface to support plain-ol-javascript-objects.

TL;DR

Removing node-fetch would require several underlying changes, and I'm too lazy to do that right now.