This requires a slightly newer graphql-extensions beta which has more arguments
to requestDidStart.
Also make it ok to not pass logFunction to formatApolloErrors, and make sure
custom fieldResolvers continue to work with extensions (by upgrading the
dependency and fixing a logic bug).
The custom fieldResolvers fix means that we now unconditionally put the
extension stack on the GraphQL context, which means that the context can no
longer be (say) a string. I changed a test that expected string contexts to
work. You couldn't use a string for a context when using extensions before, so
this isn't that big of a change.
- Actually call validationDidStart and parsingDidStart.
- Use new graphql-extensions API which:
- replaces fooDidEnd with a handler returned by fooDidStart
- adds options to various methods
- has a new willSendResponse method
- requires you to construct the extension objects yourself (but make
the external API for specifying extensions to ApolloServer be
factories, because extensions are per request)
- Make a better effort at consistently calling end handlers even on error
runQuery currently takes a `query` argument that is either a string or a
DocumentNode. This means that it's possible to accidentally support syntax we
don't mean to. For example, if you happen to send a JSON-serialized DocumentNode
over the wire, we'll happily execute that, and you'll believe you're using
GraphQL even though you really aren't --- until you try to use some other
GraphQL tool that expects to see the GraphQL query language rather than
graphql-js ASTs.
Additionally, GET requests parse their queries in runHttpQuery rather than
runQuery, leading to inconsistent error handling semantics on parse failures.
Simplify the runQuery API (which is technically exported though intended to be
mostly internal) to take in either a parsedQuery or a queryString argument. The
main use case for knowing about these parameters is if you're using formatParams
with OperationStore; its docs and tests have been updated to reflect this.
Stop parsing queries in runHttpQuery; instead, ensure we throw the right error
for mutations-over-GET by passing the error to throw into runQuery.
Stop accidentally supporting graphql-js ASTs on the wire --- but throw an
informative error when you do so.
This backwards-incompatible change is intended for apollo-server-core 2.0.
This change was introduced by the changes in apollographql/apollo-server#802
but first showed its head in apollographql/apollo-server#908. The reason that
violations in new type definitions aren't being found until subsequent PRs
isn't entirely clear but, ignoring that CI-related annoyance, the problem
itself here is very concrete.
It traces back to a major version update to `@types/mocha` via [Exhibit A],
which makes it unacceptable to return anything besides a `Promise` or
_nothing_ from a Mocha test factory.
I agree with this change in principle, since generally speaking there can be
multiple `expect` statements in each test and there is no particular reason
that the last one's value should be getting returned as Mocha doesn't do
anything functional with it.
More than anything, this seems like an artifact of an ESLint rule which
mandated that the last value in a function be returned, à la CoffeeScript or
other languages.
This will fix the failing tests on apollographql/apollo-server#908 and other
PRs currently in-flight.
Exhibit A: https://github.com/DefinitelyTyped/DefinitelyTyped/pull/24301
