BUGFIX: the playground page is currently being served without a content type
<!--
Thanks for filing a pull request on GraphQL Server!
Please look at the following checklist to ensure that your PR
can be accepted quickly:
-->
TODO:
* [x] Update CHANGELOG.md with your change (include reference to issue & this PR)
* [ ] Make sure all of the significant new logic is covered by tests
* [x] Rebase your changes on master so that they can be merged easily
* [x] Make sure all tests and linter rules pass
Follow-up on the update to `graphql-playground-html` in previous release by
also bumping the minor version of the `graphql-playground-react` dependency
to `1.7.10` — which is the version requested from the from the CDN bundle by
`graphql-playground-html`.
Ref: https://github.com/apollographql/apollo-server/pull/2037
With any luck, we will no longer necessitate our fork which removed the
`graphql-config` dependency thanks to the work done in:
https://github.com/prisma/graphql-playground/pull/874🎉
Most notably though, this fixes a documentation scrolling problem with
Safari.
This was something I just happened to spot, though further investigation is
likely necessary to determine if other similar cases can be discovered.
This fixes this test to `expect` the number of additional `expectations we
have expressed for it: 2.
Testing errors in `catch`es of `Promise` chains necessitates the use of
`expect.assertions(n)` where `n` is the number of assertions declared in
that particular test.
Without this `expect`ation clearly defined, a resolved `Promise` will not
result in the assertion being tested. For example, if the `query` passed to
this test was a query against a type in the schema (i.e. `query: 'foo'` was
replaced with `query: { query: '{ testString }' }`) the desired error would
not be produced, but the test would still pass. I'm not saying that's
likely, but there's certainly the possibility that (given fault code)
something else in the plumbing could cause that Promise to resolve.
Ref: https://jestjs.io/docs/en/tutorial-async#error-handling
This is mandated by `lru-cache` v5 and surfaced the CircleCI failures on #2004:
https://circleci.com/gh/apollographql/apollo-server/22537
Luckily, this is a private implementation detail of Apollo Server's
`InMemoryLRUCache` so no additional changes should be necessary and we should
be able to update to `lru-cache` 5.0.0 in a semver minor respectful way.
In an effort to maintain consistency and semantically correct meaning,
this changes (only in documentation and internal Apollo Server tests) the
name of the first argument in resolver signatures to use `parent` rather
than `root`.
While `root` certainly makes sense when the resolver is belonging to the
root `Query` or `Mutation` type, once nested field resolvers begin getting
called, the more semantically correct term would seem to be `parent`.
Since `parent` still makes sense at the root level, and since resolvers
frequently get copied and pasted into more deeply-nested positions, putting
this pattern in place for apps which are just beginning might just help
someone more clearly understand the relationship in the future — without
incorrectly thinking that a nested resolver is accessing the root of the
graph, rather than the parent.
Due to a number of other assignments within `createPlaygroundOptions`, the default is still maintained and the `playground` configuration parameter should be entirely optional.
I foolishly used `O.p.hasOwnProperty` here which, while safe for checking
properties, is actually not correct since this `then` property is inherited
from `Promise.prototype.then`.
Checking if `then` is a function should be safe _enough_.
Follows-up on: #1955
We expect introspection queries to behave in an synchronous manner since
they do not have any resolvers which return Promises. This expectation
seems to also be had by `graphql-js` which utilizes `graphqlSync`, rather
than `graphql` for execution of introspection queries. In fact, this may be
one of the entire reasons that `graphqlSync` exists: to fulfill a contract
for synchronous execution of server introspection. The introspection tests
within `graphql-js` seem to support this theory[[0]].
Utilities which wrap GraphQL resolvers should take care to maintain the
execution dynamics of what they are wrapping, or they should avoid wrapping
introspection types entirely by checking the type with the
`isIntrospectionType` predicate function from `graphql/type`[[1]].
[0]: 787422956c/src/type/__tests__/introspection-test.js
[1]: https://github.com/graphql/graphql-js/blob/74d1e941/src/type/introspection.js#L484.
Closes: https://github.com/apollographql/apollo-server/issues/1935
* Add correct project references for `apollo-server-cloud-functions`.
The `apollo-server-cloud-functions` has been been mis-referenced (or
referenced inconsistently) since its original inception in #1446 when its
package directory was `apollo-server-cloud-function` (singular!) and the
`package.json` referenced the plural form (`apollo-server-cloud-functions`):
https://github.com/apollographql/apollo-server/commit/724d9ff0#diff-e1d725fd66f7e9ef5251abf0437a09ca
These references have been mostly fixed in the READMEs and supporting
documentation, but the underlying monorepo directory structure has still not
been fixed, which I'm sure contributed to this module being overlooked and
unreferenced in the move to TypeScript project references in #1772.
Additionally, the lack of referencing in the monorepo's TS config has
resulted in it being broken in the most recent 2.2.0 release, as reported by
@pyros2097 and @thetre97 in: https://github.com/apollographql/apollo-server/pull/1896#issuecomment-436994955
This should fix that by properly adding the TypeScript project references.
* Sorting.
To avoid problems frequently associated with subclassing, and the possible
versioning ergonomics of subclassing the wrong version, this changes the
plugin infrastructure to no longer require subclassing the abstract class.
This was causing the `checkOperationPlugin` to be added to the list of
plugins to be executed, thus resulting in an additional plugin pass (of the
same plugin) for each request.
1st request = 1 plugin
2nd request = 2 of the same plugin
3rd request = 3 of the same plugin
Obviously, this was not intended.
