* Example code snippet does not work
for the context it needs to return a connection.context and not a {}.
* Include not about what connection contains
Due to a number of other assignments within `createPlaygroundOptions`, the default is still maintained and the `playground` configuration parameter should be entirely optional.
This updates the `renovate.json` to remove a version pinning of `lint-staged` which clearly didn't work since the current version of `lint-staged` is newer than `v7`.
This PR contains the following updates:
| Package | Type | Update | Change | References |
|---|---|---|---|---|
| @​types/node | devDependencies | patch | `10.12.6` -> `10.12.7` | [source](https://renovatebot.com/gh/DefinitelyTyped/DefinitelyTyped) |
---
### Renovate configuration
📅 **Schedule**: "after 6pm every weekday,before 8am every weekday" in timezone America/Los_Angeles.
🚦 **Automerge**: Enabled.
♻️ **Rebasing**: Whenever PR is stale, or if you modify the PR title to begin with "`rebase!`".
🔕 **Ignore**: Close this PR and you won't be reminded about this update again.
---
This PR has been generated by [Renovate Bot](https://renovatebot.com/gh/marketplace/renovate). View repository job log [here](https://renovatebot.com/dashboard#apollographql/apollo-server).
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.
* Add client awareness reference api and some docs
* Reword and add default behavior to docs
* update clientReferenceId docs to be more explicit
* Update the generateClientInfo to use headers
These are docs to accompany the `apollo-server-testing` utils
<!--
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:
* [ ] Update CHANGELOG.md with your change (include reference to issue & this PR)
* [ ] Make sure all of the significant new logic is covered by tests
* [ ] Rebase your changes on master so that they can be merged easily
* [ ] Make sure all tests and linter rules pass
<!--**Pull Request Labels**
While not necessary, you can help organize our pull requests by labeling this issue when you open it. To add a label automatically, simply [x] mark the appropriate box below:
- [ ] feature
- [ ] blocking
- [x] docs
To add a label not listed above, simply place `/label another-label-name` on a line by itself.
-->
