* 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
Fixes#1613.
We always send traces that includes an error node if the trace has an
error. In the case that sending errors is disabled, we replace the
message and remove the location.
Note that the Engine proxy strips all error information from the traces
with noErrorTraces set. To get errors to show up in the ui, the proxy
sends error counts inside of the aggregated stats reports. To get
similar behavior inside of the apollo server metrics reporting, we
always send a trace and mask out the PII.
Playground can either use external settings or its default settings (browser settings), in incompatible ways. The original implementation of default settings here would always provide 'settings' for Playground, in turn make its own settings mechanism disabled, with consequences such as altering settings in-browser cannot work as expect. Besides, once the default settings here go different with Playground provided, it would cause other problems.
The intention here is to use Playground setting as default, while explicit passing Playground settings in Apollo server would still work with defaults defined here merged.
Without this file, Netlify was choosing to build the documentation using the
npm scripts present in the root `package.json`, rather than the `package.json`
in the `docs/` directory, as it should be.
While it's strange that this behavior just cropped up around a recent swap to
using `@apollographql/apollo-upload-server`, I suspect that the problem is
more deeply rooted than that and we were just accidentally getting away with
the past behavior - which was defined less explicitly in the Netlify UI.
Now, with this `netlify.toml` file, we can run the exact build step we need
for documentation and also gain the ability to have per-branch control over
that configuration, which has been necessary in the past.
