Since activating the EngineReportingAgent is now dependent on being able to extract an engineServiceId from the API key, tests need to specify one that follows the expected structure.
We compile `requestPipelineAPI.ts` as a separate TypeScript project to avoid circular dependency issues from the `apollo-server-plugin-base` package depending on the types in `apollo-server-core`.
We can't use `apollo-server-env` as a project reference because that requires `composite: true`, and that implies `declaration: true`, which doesn't work for `apollo-server-env` because we need to write our own declaration files for re-exported imports.
This commit also removes `apollo-engine-reporting-protobuf` as a reference, which errored out because it doesn't actually contain any TypeScript code.
While cacheControl can take a boolean when passing it in to ApolloServer as part of a Config, these will be converted to default options before passing them on as options.
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.
> ```
The actual resolving of the context happens in ApolloServer#graphQLServerOptions, but errors thrown while doing that are currently converted to a throwing function.
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.
> ```
The `generateClientInfo` API, used to set client identification attributes
within traces, is an experimental API and is subject to removal or change in
a future (major) Apollo Server release.
Ref: #1631
* 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
Some changes are easier to mentally consume before they've been prettier'd.
While I'll certainly allow Prettier to do what it wants to do, I've confined
it's changes to this commit for easier reviewability.
Note to the reviewer: this commit is exactly the result of running the
`npm run lint-fix` command on a clean Git working tree.
Ref: c9375c405b
The techniques previously used to skip particular tests for particular
Node.js versions (for example, file uploads, Hapi, etc.) were problematic in
a couple ways:
1. `return`-ing outside a function (say, at the top level of a module) is
not valid ECMAScript. While it works in this current state, it only works
because of Babel's wrapping scope. As we move toward less and less
transpiled modules, this would become problematic anyway, but it's a
short-term blocker for me since I intend on dropping the `skipBabel` option
we currently pass to` `ts-jest` in its current (`package.json`)
configuration. (My editor also dislikes top-level `return`, expectedly.)
2. By `return`-ing from a test which we wish to skip conditionally, we avoid
the awareness which is provided by Jest (automatically) when using its
built-in `.skip` helpers. By switching to technique I've employed here,
we're able to see `<num> skipped` in Jest's output and (rightfully) be able
to question why something is being skipped.
By using the `atLeastMajorNodeVersion` helper, we'll also be able to more
easily find where this pattern is used in test-cases, to more easily
re-evaluate their use-cases when we add support newer Node.js versions.
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
