Commit graph

14 commits

Author SHA1 Message Date
David Glasser
5c65742a39
Factor out runQuery's use of logFunction into an extension (#1128)
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.
2018-06-01 21:16:25 -07:00
David Glasser
836616bd04 Turn on noUnusedLocals and noUnusedParameters (#1126) 2018-06-01 15:16:16 -07:00
David Glasser
7444904518 Update for graphql-extensions@0.1.0 API
- 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
2018-05-31 00:14:59 -07:00
Sebastian
2acf5654c3 Added an option to support additional extensions
(Originally #934, tweaked by @glasser.)
2018-05-31 00:14:59 -07:00
Evans Hauser
da316908d2
runQuery accepts Request object that variants create (#1108)
* core: runQuery accepts Request object that integrations create

* core: add changelog for Requst in runQuery

* adonis: correct request object passed to runQuery

* core: change convertHttpMessageToRequest to convertNodeHttpToRequest
2018-05-29 21:37:38 -07:00
David Glasser
8b6b0161d1
Be consistent about where GraphQL queries are parsed
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.
2018-05-24 15:47:09 -07:00
Evans Hauser
f6eece6294
apollo-server-core: move logging into separate file 2018-05-11 15:53:16 -07:00
Evans Hauser
cdf4c6860d
apollo-server-core: fix error printing and logging tests 2018-05-11 15:53:15 -07:00
Jesse Rosenberger
0a103ef5bd
Stop violating types by returning assertions from Mocha tests. (#972)
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
2018-04-18 15:37:47 +03:00
Sashko Stubailo
281392c3f0 Update to graphql@0.12 (#726)
* Update peer deps and tests for 0.12
* v1.3.2
2018-03-13 17:10:37 +02:00
Laurin Quast
df51fd90da Setup prettier (#724)
* Setup prettier and precommit hooks

* Format code with prettier

* Use husky because it works...

* Move prettier config to .prettierrc file

* Implement fixing markdown file formatting when running lint-fix script

* Format markdown files

* Add .json file formatting

* Fixes json file formatting

* Add pretteir linting step

* Remove tslint

* Use gitignore for prettier

* Fix linting errors

* Ignore submodule folder
2018-01-08 15:08:01 -08:00
Dom Armstrong
a8ae9042f5 Fix apollo-server-core runQuery breaks async_hook tracking (#733)
By creating a promise out of the execution flow the ability to trace the
async call stack is lost.
2017-12-22 05:46:02 +01:00
Mikhail Novikov
c51fc65da8 Add ability to provide default field resolvers (#482) 2017-08-02 12:20:10 +02:00
Martijn Walraven
300c0cd12b Rename packages from graphql-server- to apollo-server- (#465) 2017-07-17 16:29:40 -07:00
Renamed from packages/graphql-server-core/src/runQuery.test.ts (Browse further)