fix(deps): Narrow graphql peerDependencies to versions that actually work

[trevor-scheer]

Related issue surfaced in #904.

The query planner and composition packages have made some changes recently which make use of a couple things only supported in graphql@15+. This makes the current peerDependencies entry "^14.5.0 || ^15.0.0" invalid.

In an attempt to keep the range as wide as possible, I tested each graphql v15 minor and landed on v15.4.0 as the earliest version that we still actually support based on the features of the package that we currently use.

I've also made the decision to align this version requirement across all of the federation packages for the sake of consistency. Unfortunately, with the @apollo/federation package concerning both subgraphs and composition, this will require subgraph operators to also upgrade their graphql version in order to use the latest @apollo/federation package.

Going forward, we really ought to land on some automated testing that will catch this if we intend to support a range of graphql versions. Especially within the federation repo, it's easy to reach for the latest and greatest features in the graphql package (and sometimes required if we want to build out support for the newest language features!).

Fixes #904

[martijnwalraven]

This looks like a very reasonable change. We should look into testing these packages with all supported graphql-js versions in CI, but that makes it even more important we keep the number of versions small (plus the cost of maintaining workarounds for keeping backwards and/or not being able to use new features).

For the gateway specifically (and that includes composition and query planning), we may want to limit ourselves to a single supported version in the future, and we could even consider making that a real (not peer) dependency so it's automatically upgraded for people (not sure what the npm 7 behavior is for upgrades of peer dependencies, maybe that is enough).

A prerequisite for that is breaking out @apollo/federation however, because we don't want to force such a strict dependency on subgraphs.

[abernix]

CHANGELOG and

[robross0606]

with the @apollo/federation package concerning both subgraphs and composition, this will require subgraph operators to also upgrade their graphql version in order to use the latest @apollo/federation package.

Would be very helpful to understand what this means from services deployment perspective. If we have an architecture with multiple services and a gateway, are you saying that all components of that architecture (services and gateway) will need to be upgraded to this version of @apollo/federation and graphql in order to function together?

I'm concerned about which versions of these libraries can be be mixed and matched together across service boundaries. For example, can we upgrade a service while the gateway is still on an older version? The reverse?

[trevor-scheer]

@robross0606 These specific dependency concerns are isolated to singular services at a time, and don't concern subgraph/gateway compatibility. There is no expected lock-stepping of your subgraphs to your gateway with respect to graphql version or @apollo/federation version.

However...
In the future, there may be additional language features introduced, i.e. #912

In a case like this, if you choose to upgrade and use that feature in a subgraph, it may require you to update your gateway version as well to introduce the same support during composition.

[robross0606]

There is no expected lock-stepping of your subgraphs to your gateway with respect to graphql version or @apollo/federation version.

Great, that's good to know. Thank you for the clarification.