Prior to embarking on the request pipeline work, and to facilitate
development on the new request pipeline, @martijnwalraven and myself
intentionally reverted some commits that had been recently introduced but
conflicted with the request pipeline branch that was already in-flight.
Rather than dealing with an incredibly difficult merge conflict, it was
easier to revert them an re-apply them later.
Original commits, reversions, and reintroductions:
* 6d6c9ff, 03a894d, b90ccc2
* 96af44e, 68c82e6, 81c4642
* 408198e, 2b470e1, 84bc834
* 4175f1b, 38e7b6a, 261994c
As is demonstrated by this short follow-up commit, this was all that was
necessary to make it work in the new model - once that model was finished.
While we're certain that the new request pipeline and its plugin model will
actually better support some of the behavior that required these initial
commits in the name of not introducing breaking changes, we feel it's
necessary to maintain their support.
I will point out, if you are at all affected by the above commits, we may
consider deprecating portions of those APIs in the not too distant future,
but we hope that the new model will help support those needs even better.
* Pass the context along to all the extension methods
Addresses #1343
With this change you should now be able to implement an extension like so:
```javascript
class MyErrorTrackingExtension extends GraphQLExtension {
willSendResponse(o) {
const { context, graphqlResponse } = o
context.trackErrors(graphqlResponse.errors)
return o
}
}
```
Edit by @evans :
fixes#1343fixes#614 as the request object can be taken from context or from requestDidStart
fixes#631 ""
* Remove context from extra extension functions
The context shouldn't be necessary for format, parse, validation, and
execute. Format generally outputs the state of the extension. Parse and
validate don't depend on the context. Execution includes the context
argument as contextValue
* Move change entry under vNext
Since activating the EngineReportingAgent is now dependent on being able to extract an engineServiceId from the API key, tests need to specify one that follows the expected structure.
We compile `requestPipelineAPI.ts` as a separate TypeScript project to avoid circular dependency issues from the `apollo-server-plugin-base` package depending on the types in `apollo-server-core`.
We can't use `apollo-server-env` as a project reference because that requires `composite: true`, and that implies `declaration: true`, which doesn't work for `apollo-server-env` because we need to write our own declaration files for re-exported imports.
This commit also removes `apollo-engine-reporting-protobuf` as a reference, which errored out because it doesn't actually contain any TypeScript code.
While cacheControl can take a boolean when passing it in to ApolloServer as part of a Config, these will be converted to default options before passing them on as options.
This silences the deprecation messages which have been showing up in recent
local development on the new request pipeline work. e.g.:
> ```
> [DEP0010] DeprecationWarning: crypto.createCredentials is deprecated.
> Use tls.createSecureContext instead.
> [DEP0011] DeprecationWarning:
> crypto.Credentials is deprecated. Use tls.SecureContext instead.
> ```
The actual resolving of the context happens in ApolloServer#graphQLServerOptions, but errors thrown while doing that are currently converted to a throwing function.
This silences the deprecation messages which have been showing up in recent
local development on the new request pipeline work. e.g.:
> ```
> [DEP0010] DeprecationWarning: crypto.createCredentials is deprecated.
> Use tls.createSecureContext instead.
> [DEP0011] DeprecationWarning:
> crypto.Credentials is deprecated. Use tls.SecureContext instead.
> ```
