Make AS/ASP invariant in TContext; move logger/cache to server in plugins #6668
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
❌ Deploy Preview for apollo-server-docs failed.
|
|
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. Latest deployment of this branch, based on commit 99303ac:
|
…gins
This change does two things, which we originally thought were kind of
connected but maybe aren't.
First, we switch the implementation of contravariance from a hacky
`__forceTContextToBeContravariant` field to the new TS 4.7 variance
annotations. But in fact, instead of making it contravariant, we make it
invariant: `ApolloServer<X>` can only be assigned to `ApolloServer<Y>`
when X and Y are the same. This is because:
- An `ApolloServer<{foo: number}>` is not a `ApolloServer<{}>`, because
you can invoke `executeOperation` on the latter with an empty context
object, which would confuse the former (this is the contravariance we
already had).
- An `ApolloServer<{}>` is not a `ApolloServer<{foo: number}>`, because
you can invoke `addPlugin` on the latter with a plugin whose methods
expect to be called with a `contextValue` with `{foo: number}` on it,
which isn't the case for the former.
Considering the second condition is why this is now invariant (`in
out`). We're not quite sure why TS couldn't figure this out for us, but
it can't.
Second, we add `server: ApolloServer` to various plugin hook arguments
(`GraphQLRequestContext` and `GraphQLServerContext`). This makes
`logger` and `cache` on `GraphQLRequestContext` somewhat redundant, so
we make those fields into public readonly fields on `ApolloServer` and
remove them from the plugin hook arguments. (We thought this was related
to the other part because adding `server` appeared to require invariance
instead of contravariance, but it turns out that we needed invariance
anyway due to `addPlugin`.)
Note that this means that anyone consuming our `.d.ts` files must be on
TS4.7. Before v4.0.0 we'll probably fix that; see #6423.
Fixes #6264. Fixes #6082.
glasser
force-pushed
the
glasser/invariance
branch
from
c1c5301
to
99303ac
Compare
This was referenced Jul 12, 2022
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This change does two things, which we originally thought were kind of
connected but maybe aren't.
First, we switch the implementation of contravariance from a hacky
__forceTContextToBeContravariantfield to the new TS 4.7 varianceannotations. But in fact, instead of making it contravariant, we make it
invariant:
ApolloServer<X>can only be assigned toApolloServer<Y>when X and Y are the same. This is because:
ApolloServer<{foo: number}>is not aApolloServer<{}>, becauseyou can invoke
executeOperationon the latter with an empty contextobject, which would confuse the former (this is the contravariance we
already had).
ApolloServer<{}>is not aApolloServer<{foo: number}>, becauseyou can invoke
addPluginon the latter with a plugin whose methodsexpect to be called with a
contextValuewith{foo: number}on it,which isn't the case for the former.
Considering the second condition is why this is now invariant (
in out). We're not quite sure why TS couldn't figure this out for us, butit can't.
Second, we add
server: ApolloServerto various plugin hook arguments(
GraphQLRequestContextandGraphQLServerContext). This makesloggerandcacheonGraphQLRequestContextsomewhat redundant, sowe make those fields into public readonly fields on
ApolloServerandremove them from the plugin hook arguments. (We thought this was related
to the other part because adding
serverappeared to require invarianceinstead of contravariance, but it turns out that we needed invariance
anyway due to
addPlugin.)Note that this means that anyone consuming our
.d.tsfiles must be onTS4.7. Before v4.0.0 we'll probably fix that; see #6423.
Fixes #6264. Fixes #6082.