This silences the deprecation messages which have been showing up in recent
local development on the new request pipeline work. e.g.:
> ```
> [DEP0010] DeprecationWarning: crypto.createCredentials is deprecated.
> Use tls.createSecureContext instead.
> [DEP0011] DeprecationWarning:
> crypto.Credentials is deprecated. Use tls.SecureContext instead.
> ```
* Provide ability to specify client info in traces
Adds the createClientInfo to apollo-engine-reporting, which enables the
differentiation of clients based on the request, operation, and
variables. This could be extended to include the response. However for
the first release. It doesn't quite make sense.
* Use extensions and context in createClientInfo
* Remove support for clientAddress
The frontend will not support it in the near future
* create -> generate and make default generator
createClientInfo -> generateClientInfo
* Clarify default values
* Allow an optional function to resolve the rootValue
Passes the parsed DocumentNode AST to determine the root value,
useful when providing a different rootValue for query vs mutation
* Add API docs for rootValue
I'm reverting apollographql/apollo-server#1698 not because it's been problematic in any way, but because I'd like to give it a bit more thought and don't want this to accidentally get cut into a release prior to that consideration.
More specifically: The `graphql-tools` update on its own shouldn't really cause any problems, but the [4.x version of `graphql-tools`](https://github.com/apollographql/graphql-tools/releases/tag/4.0.0) is intended to support and enable the latest `graphql@14` which contains [breaking changes](https://github.com/graphql/graphql-js/releases/tag/v14.0.0).
I believe most of those breaking changes would be show-stoppers and the failures would surface immediately (meaning that servers would completely fail to start, rather than being a surprise in other, more delayed scenarios), but it's still worth pausing and carefully considering versioning to avoid any surprises.
That said, the 14.x version of `graphql` has been an acceptable range in the `peerDependencies` of `apollo-server-*` since before its final release came out, and I don't believe we've caught wind of anything that a major version bump would have prevented or made more clear. In the end, `graphql` is a peer dependency and any problems should only surface if consumers also update their `graphql` dependency — a clear major version bump, which deserves review by the upgrader — so perhaps we can avoid bumping the major version after all?
Input welcomed, but again, merging this now to give this a bit more thought first.
cc @hwillson
`esModuleInterop` was enabled in
e4164c8892
to help with importing from packages that use default exports.
Those changes were reverted in
https://github.com/apollographql/apollo-server/pull/1210
to work around a few reported issues. Those issues are no longer
relevant, so this commit re-enables `esModuleInterop`, and
updates all default imports to use the more common (standard)
import syntax.
* Allow an optional function to resolve the rootValue
Passes the parsed DocumentNode AST to determine the root value,
useful when providing a different rootValue for query vs mutation
* Add API docs for rootValue
* Specify explicit `cursorShape` to avoid missing cursor in GraphQL Playground.
This solves a problem with the text cursor caret not being visible in the
operation input box within GraphQL Playground by explicitly setting a
GraphQL Playground configuration option called `cursorShape` to `line`.
All credit for the actual solution goes to @lpellegr for their discovery in
https://github.com/prisma/graphql-playground/issues/790#issuecomment-409221277
* Update CHANGELOG.md
* Provide ability to specify client info in traces
Adds the createClientInfo to apollo-engine-reporting, which enables the
differentiation of clients based on the request, operation, and
variables. This could be extended to include the response. However for
the first release. It doesn't quite make sense.
* Use extensions and context in createClientInfo
* Remove support for clientAddress
The frontend will not support it in the near future
* create -> generate and make default generator
createClientInfo -> generateClientInfo
* Clarify default values
* 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
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.
* Switch to a fork of `apollo-upload-server` to fix missing `core-js` dependency.
As reported in https://github.com/apollographql/apollo-server/issues/1542,
the `apollo-upload-server` package (v5.0.0, which `apollo-server` relies on)
is no longer able to provide a `core-js` package because of change that was
outside of its control in a Babel release.
The problem is resolved in newer versions of `apollo-upload-server`,
however, regrettably, the newer versions of that package (notably, v6 and
v7) drop support for Node.js 6 — one of two versions of Node.js that are
currently under the terms of the Node.js Foundation's Long-Term-Support
(LTS) agreements.
Since Apollo Server aims to support versions of Node.js which are under LTS
(and will drop support for Node.js 6 in April 2019, per Node.js' schedule)
the current, immediate solution is to fork the `apollo-upload-server`
package as `@apollographql/apollo-upload-server`.
With the inclusion of
https://github.com/apollographql/apollo-upload-server/pull/1, we are able to
keep supporting Node.js 6. Without this change, every new installation
of `apollo-server`, which doesn't have a `package-lock.json` preventing
transitive dependency updates - specifically, the updates to
`@babel/runtime` versions newer than `-beta.56` - is broken.
* [squash] Update to `@apollographql/apollo-upload-server@5.0.2`.
* [squash] Update to `@apollographql/apollo-upload-server@5.0.3`.
* Pass payload into the context function for subscriptions
The payload can be used for things like auth. You can pass a token on
the payload of the message and use it to fetch the user.
* Update CHANGELOG.md
* Fixed support for GraphQL Playground with custom configuration in production environments.
* Updated logic in `createPlaygroundOptions` to cast the `playground` option to a boolean
if it is defined. Fall back to `isDev` logic only if undefined.
* Updated unit test for partial graphql playground options to emulate a 'production'
environment, mimicking the scenario that was broken before.
* Add PR #1495 to CHANGELOG.
* Restore partial playground options test when no `NODE_ENV`
