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`.
