Update dependency apollo-server-testing to v2.25.0

[renovate]

This PR contains the following updates:

Package	Change	Age	Adoption	Passing	Confidence
apollo-server-testing	2.11.0 -> 2.25.0

---

Release Notes

apollographql/apollo-server

v2.25.0

Compare Source

• apollo-server-core: You may now specify your Studio graph as a graph ref (id@variant) via the APOLLO_GRAPH_REF environment variable or new ApolloServer({apollo: {graphRef}}) instead of specifying graph ID and graph variant separately. The apollo object passed to plugin serverWillStart and to gateway load now contains a graphRef field.
• apollo-server-core: Fix a race condition where schema reporting could lead to a delay at process shutdown. PR #​5222
• apollo-server-core: Allow the Fetch API implementation to be overridden for the schema reporting and usage reporting plugins via a new fetcher option. PR #​5179
• apollo-server-core: The server.executeOperation method (designed for testing) can now take its query as a DocumentNode (eg, a gql-tagged string) in addition to as a string. (This matches the behavior of the apollo-server-testing createTestClient function which is now deprecated.) We now recommend this method instead of apollo-server-testing in our docs. Issue #​4952
• apollo-server-testing: Replace README with a deprecation notice explaining how to use server.executeOperation instead. Issue #​4952

v2.24.1

Compare Source

• apollo-server-core: Fix a typo that could lead to TypeScript compilation when combined with a recent version of @types/node. (This bug had no runtime effect.) PR #​5149

v2.24.0

Compare Source

• apollo-server-core: Apollo Studio usage reporting uses a more efficient format which sends fewer detailed traces to Apollo's server. This change should not have a major effect on the experience of using Apollo Studio. PR #​4142

v2.23.0

Compare Source

• apollo-server-core: Add optional argument to ApolloServer.executeOperation allowing the caller to manually specify an argument to the config function analogous to that provided by integration packages. PR #​4166 Issue #​2886
• [email protected]: New BaseRedisCache class which takes an ioredis-compatible Redis client as an argument. The existing classes RedisCache and RedisClusterCache (which pass their arguments to ioredis constructors) are now implemented in terms of this class. This allows you to use any of the ioredis constructor forms rather than just the ones recognized by our classes. This also fixes a long-standing bug where the Redis cache implementations returned a number from delete(); it now returns a number, matching what the KeyValueCache interface and the TypeScript types expect. PR #​5034 PR #​5088 Issue #​4870 Issue #​5006
• apollo-server-core: Fix type for formatResponse function. It never is called with a null argument, and is allowed to return null. Issue #​5009 PR #​5089
• apollo-server-lambda: Fix regression in v2.21.2 where thrown errors were replaced by throwing the JS Error class itself. PR #​5085
• apollo-server-core: If a client sends a variable of the wrong type, this is now reported as an error with an extensions.code of BAD_USER_INPUT rather than INTERNAL_SERVER_ERROR. PR #​5091 Issue #​3498
• apollo-server-lambda: Explicitly support API Gateway payloadFormatVersion 2.0. Previously some codepaths did appropriate checks to partially support 2.0 and other codepaths could lead to errors like event.path.endsWith is not a function (especially since v2.21.1). Note that this changes the TypeScript typing of the onHealthCheck callback passed to createHandler to indicate that it can receive either type of event. If you are using TypeScript and care about having a precise typing for the argument to your onHealthCheck callback, you should determine which payload format you want to support and write new ApolloServer<APIGatewayProxyEvent>(...) or new ApolloServer<APIGatewayProxyEventV2>(...) (importing these types from aws-lambda), or differentiate between the two formats by checking to see if 'path' in event. Issue #​5084 Issue #​5016

v2.22.2

Compare Source

• apollo-server-core: Fix a regression in v2.22.0 where combining apollo-server-core v2.22 with an older version of an integration package could lead to startup errors like called start() with surprising state invoking serverWillStart. The fix involves changing the semantics of the protected willStart method (which is left in only for backwards compatibility). Issue #​5065 Issue #​5066 PR #​5073

v2.22.1

Compare Source

• apollo-server-core: Fix a regression in v2.22.0 where startup errors could be thrown as part of the GraphQL response instead of redacted in one edge case. PR #​5064

v2.22.0

Compare Source

• Improve startup error handling by ensuring that your server has loaded its schema and executed its serverWillStart handlers successfully before starting an HTTP server. If you're using the apollo-server package, no code changes are necessary. If you're using an integration such as apollo-server-express that is not a "serverless framework", you can insert await server.start() between server = new ApolloServer() and server.applyMiddleware. (If you don't call server.start() yourself, your server will still work, but the previous behavior of starting a web server that may fail to load its schema still applies.) The serverless framework integrations (Lambda, Azure Functions, and Cloud Functions) do not support this functionality. While the protected method willStart still exists for backwards compatibility, you should replace calls to it with start or the new protected method ensureStarting. PR #​4981

v2.21.2

Compare Source

• apollo-server-core: The SIGINT and SIGTERM signal handlers installed by default (when not disabled by stopOnTerminationSignals: false) now stay active (preventing process termination) while the server shuts down, instead of letting a second signal terminate the process. The handlers still re-signal the process after this.stop() concludes. Also, if this.stop() throws, the signal handlers will now log and exit 1 instead of throwing an uncaught exception. Issue #​4931
• apollo-server-lambda: Refactor the handler returned by server.createHandler so that if it is not passed a callback, it acts as an async handler instead of a non-async handler. This means you can wrap it in your own async handler without having to create a callback, and makes the code more maintainable. Issue #​1989 PR #​5004

v2.21.1

Compare Source

• apollo-server-lambda: The onHealthCheck option did not previously work. Additionally, health checks (with onHealthCheck or without) didn't work in all Lambda contexts, such as behind Custom Domains; the path check is now more flexible. Issue #​3999 PR #​4969 Issue #​4891 PR #​4892
• The debug option to new ApolloServer (which adds stack traces to errors) now affects errors that come from requests executed with server.executeOperation (and its wrapper apollo-server-testing), instead of just errors that come from requests executed over HTTP. Issue #​4107 PR #​4948
• Bump version of @apollographql/graphql-playground-html to v1.6.27 and @apollographql/graphql-playground-react to v1.7.39 to resolve incorrectly rendered CDN URL when Playground version was false-y. PR #​4932 PR #​4955 Issue #​4937

v2.21.0

Compare Source

• Apollo Server can now be installed with graphql@15 without causing peer dependency errors or warnings. (Apollo Server has a file upload feature which was implemented as a wrapper around the graphql-upload package. We have been unable to upgrade our dependency on that package due to backwards-incompatible changes in later versions, and the version we were stuck on did not allow graphql@15 as a peer dependency. We have now switched to a fork of that old version called @apollographql/graphql-upload-8-fork that allows graphql@15.) Also bump the graphql-tools dependency from 4.0.0 to 4.0.8 for graphql@15 support. Issue #​4865

v2.20.0

Compare Source

• apollo-server: Previously, ApolloServer.stop() functioned like net.Server.close() in that it did not close idle connections or close active connections after a grace period. This meant that trying to await ApolloServer.stop() could hang indefinitely if there are open connections. Now, this method closes idle connections, and closes active connections after 10 seconds. The grace period can be adjusted by passing the new stopGracePeriodMillis option to new ApolloServer, or disabled by passing Infinity (though it will still close idle connections). Note that this only applies to the "batteries-included" ApolloServer in the apollo-server package with its own built-in Express and HTTP servers. PR #​4908 Issue #​4097
• apollo-server-core: When used with ApolloGateway, ApolloServer.stop now invokes ApolloGateway.stop. (This makes sense because ApolloServer already invokes ApolloGateway.load which is what starts the behavior stopped by ApolloGateway.stop.) Note that @apollo/gateway 0.23 will expect to be stopped in order for natural program shutdown to occur. PR #​4907 Issue #​4428
• apollo-server-core: Avoid instrumenting schemas for the old graphql-extensions library unless extensions are provided. PR #​4893 Issue #​4889
• [email protected]: The shouldReadFromCache and shouldWriteToCache hooks were always documented as returning ValueOrPromise<boolean> (ie, that they could be either sync or async), but they actually only worked if they returned a bool. Now they can be either sync or async as intended. PR #​4890 Issue #​4886
• [email protected]: The RESTDataSource.trace method is now protected instead of private to allow more control over logging and metrics. PR #​3940

v2.19.2

Compare Source

• apollo-server-express: types: Export ExpressContext from main module. PR #​4821 Issue #​3699
• apollo-server-env: types: The first parameter to fetch is now marked as required, as intended and in accordance with the Fetch API specification. PR #​4822 Issue #​4741
• apollo-server-core: Update graphql-tag package to latest, now with its graphql-js peerDependencies expanded to include ^15.0.0 PR #​4833

v2.19.1

Compare Source

• apollo-server-core: The debugPrintReports option to ApolloServerPluginUsageReporting now prints traces as well. PR #​4805

v2.19.0

Compare Source

• apollo-server-testing: types: Allow generic variables usage of query and mutate functions. PR #​4383
• apollo-server-express: Export the GetMiddlewareOptions type. PR #​4599
• apollo-server-lambda: Fix file uploads - ignore base64 decoding for multipart queries. PR #​4506
• apollo-server-core: Do not send operation documents that cannot be executed to Apollo Studio. Instead, information about these operations will be combined into one "operation" for parse failures, one for validation failures, and one for unknown operation names.

v2.18.2

Compare Source

• apollo-server-core: Explicitly include lru-cache dependency in apollo-server-core's dependencies. PR #​4600

v2.18.1

Compare Source

• apollo-server-core: Fix support for legacy option engine: {logger}, broken in v2.18.0. PR #​4588

• apollo-server-plugin-base: The ApolloServerPlugin TypeScript type does not need to extend AnyFunctionMap, which was an unnecessary change in v2.18.0. PR #​4588

• apollo-server-core: Improve a usage reporting error which occurs when you use Apollo Server in an unsupported way. PR #​4588

• apollo-server-core: Fix typo in error message for unparsable/invalid schemas provided via overrideReportedSchema. PR #​4581

v2.18.0

Compare Source

• apollo-server-core: When Apollo Server is configured with an Apollo API key, the URLs it uses to connect to Apollo's servers have changed. If the environment in which you run your servers requires you to explicitly allow connections by domain, you will need to add the new domain names. Usage reporting previously connected to https://engine-report.apollodata.com/ and now connects to https://usage-reporting.api.apollographql.com/; schema reporting previously connected to https://edge-server-reporting.api.apollographql.com/ and now connects to https://schema-reporting.api.apollographql.com/ . PR #​4453

• Apollo Server's support for communicating with Apollo’s commercial products has been refactored into three separate plugins exported from apollo-server-core (for usage reporting, schema reporting, and inline tracing), configured using the standard plugins option. The engine option continues to work for backwards compatibility in the 2.x series; support for engine will be deprecated in Apollo Server 3.x. Full details are available in the migration guide. PR #​4453

• To consistently support tracing, inline tracing is enabled by default on federated implementing services, even when an Apollo API key is provided. Previously it was not enabled when an API key was provided. You can disable it with ApolloServerPluginInlineTraceDisabled. PR #​4453

• The apollo-engine-reporting npm package has been obsoleted and will no longer receive updates. PR #​4453

• The apollo-engine-reporting-protobuf package has been renamed to apollo-reporting-protobuf. No new versions of the old package will be published. PR #​4453

• Implementations of ApolloServer for serverless frameworks such as Lambda now override the serverlessFramework() method to return true. We have changed our own integrations, but other implementations that extend ApolloServer which need this behavior should do the same. Support for engine.sendReportsImmediately will be dropped in Apollo Server 3.x. PR #​4453

• The GraphQLServiceContext type passed to the plugin serverWillStart method now contains apollo and serverlessFramework values. PR #​4453

• apollo-server-core / apollo-server-plugin-base: The request pipeline plugin API now supports a serverWillStop lifecycle hook. PR #​4453

• apollo-server-core: Previously, the usage reporting functionality registered one-shot handlers for the SIGINT and SIGTERM signals, which it used to send one final usage report before re-sending the signal to itself to continue shutdown. These signals handlers were installed by default if you enabled usage or schema reporting, and could be disabled by passing engine.handleSignals: false. Now, termination signal handling is the responsibility of Apollo Server as a whole rather than something specific to usage reporting. Apollo Server itself now registers these one-shot signal handlers, which trigger ApolloServer.stop(). This allows any plugin that implements the new serverWillStop callback to hook into shutdown logic, not just the usage reporting code. Similarly to before, these signal handlers are registered by default but can be disabled by via an option. We've changed the option name to stopOnTerminationSignals: false as it is more explicit about the behavior. PR #​4453

• apollo-server-core: The default logger implementation (if you don't specify your own logger or specify debug) now logs at the INFO level instead of the WARN level. The main effect is on a few built-in plugins which log one INFO message at startup; if a custom plugin logs at the INFO level then those messages will be visible by default as well. PR #​4453

• apollo-server-core: Parse and validate any schema passed via overrideReportedSchema to the schema reporting plugin, and throw accordingly on unparsable or invalid schemas.

• Using Apollo Server from TypeScript now requires TypeScript 3.8 due to the use of the import type and export type directives. (If this proves to be a major problem we can revert this choice, but it makes it easier for us to ensure that certain large dependencies are only loaded when needed.) PR #​4453

• Updated @apollographql/graphql-playground-react to 1.7.33 to include an upstream fix. PR #​4550

v2.17.0

Compare Source

• subscriptions: Fix bug which prevented installSubscriptionHandlers from accepting a websocket.Server (as intended in PR #​1966) and also added support for other http.Server variations (e.g., Tls). Issue #​4198 PR #​4200

v2.16.1

Compare Source

• This release only includes patch updates to dependencies.

v2.16.0

Compare Source

• apollo-server-fastify: Pass Fastify's request and reply objects into the context function, which previously had been receiving nothing. Issue #​3156 [PR #​3895(apollo-server-fastify's context function now receives reply object. apollographql/apollo-server#3895)
• apollo-server-lamdbda: Automatically decode payloads which are Base64-encoded when the isBase64Encoded boolean is present on Lambda event payloads. PR #​4311

v2.15.1

Compare Source

• The default branch of the repository has been changed to main. As this changed a number of references in the repository's package.json and README.md files (e.g., for badges, links, etc.), this necessitates a release to publish those changes to npm. PR #​4302

v2.15.0

Compare Source

• apollo-engine-reporting: Added a reportTiming API to allow trace reporting to be enabled or disabled on a per request basis. The option takes either a boolean or a predicate function that takes a GraphQLRequestContextDidResolveOperation or GraphQLRequestContextDidEncounterErrors and returns a boolean. If the boolean is false the request will not be instrumented for tracing and no trace will be sent to Apollo Graph Manager. The default is true so all traces will get instrumented and sent, which is the same as the previous default behavior. PR #​3918
• apollo-engine-reporting: Removed GraphQLServerOptions.reporting. It isn't known whether a trace will be reported at the beginning of the request because of the above change. We believe this field was only used internally within Apollo Server; let us know if this is a problem and we can suggest alternatives. Additionally, the field requestContext.metrics.captureTraces is now initialized later in the request pipeline. PR #​3918
• apollo-engine-reporting: Make Apollo Server throw if schema reporting is enabled for a gateway or federated service. PR #​4246
• apollo-engine-reporting: Remove the experimental_ prefix from schema reporting options, and specifically rename experimental_schemaReporting option name to reportSchema. (The old option names remain functional, but are deprecated.) PR #​4236

v2.14.5

Compare Source

• apollo-engine-reporting: Make Apollo Server throw if schema reporting is enabled for a gateway or federated service. PR #​4246

v2.14.4

Compare Source

• apollo-engine-reporting: Add environment variable APOLLO_SCHEMA_REPORTING that can enable schema reporting. If experimental__schemaReporting is set it will override the environment variable. PR #​4206
• apollo-engine-reporting: The schema reporting URL has been changed to use the new dedicated sub-domain https://edge-server-reporting.api.apollographql.com. PR #​4232
• apollo-server-core: Though Apollo Server is not affected due to the way it is integrated, in response to an upstream security advisory for GraphQL Playground we have published the same patch on our @apollographql/graphql-playground-html fork and bumped Apollo Server to use it. Again, this was done out of an abundance of caution since the way that Apollo Server utilizes renderPlaygroundPage is not vulnerable as it does not allow per-request Playground configuration that could allow interpolation of user-input. PR #​4231

v2.14.3

Compare Source

• This release only includes patch updates to dependencies.

v2.14.2

Compare Source

Note: This release is is related to a GitHub Security Advisory published by the Apollo Server team. Please read the attached advisory to understand the impact.

• ⚠️ SECURITY: Pass all schema validation rules to the subscription server, including validation rules that restrict introspection when introspection is meant to be disabled. Read the full GitHub Security Advisory for details.

v2.14.1

Compare Source

See complete versioning details.

• apollo-server-testing: Ensure that user-provided context is cloned when using createTestClient, per the instructions in the intergration testing section of the Apollo Server documentation. Issue #​4170 PR #​4175

v2.14.0

Compare Source

See complete versioning details.

• apollo-server-core / apollo-server-plugin-base: Add support for willResolveField and corresponding end-handler within executionDidStart. This brings the remaining bit of functionality that was previously only available from graphql-extensions to the new plugin API. The graphql-extensions API (which was never documented) will be deprecated in Apollo Server 3.x. To see the documentation for the request pipeline API, see its documentation. For more details, see the attached PR. PR #​3988

• apollo-server-core: Deprecate graphql-extensions. All internal usages of the graphql-extensions API have been migrated to the request pipeline plugin API. For any implementor-supplied extensions, a deprecation warning will be printed once per-extension, per-server-startup, notifying of the intention to deprecate. Extensions should migrate to the plugin API, which is outlined in its documentation. PR #​4135

• apollo-engine-reporting: Currently only for non-federated graphs.
  Added an experimental schema reporting option,
  experimental_schemaReporting, for Apollo Graph Manager users. During
  this experiment, we'd appreciate testing and feedback from current and new
  users of the schema registry!

  Prior to the introduction of this feature, the only way to get schemas into
  the schema registry in Apollo Graph Manager was to use the CLI and run
  apollo schema:push. Apollo schema reporting protocol is a new
  specification for GraphQL servers to automatically report schemas to the
  Apollo Graph Manager schema registry.

  To enable schema reporting, provide a Graph Manager API key (available
  free from Apollo Graph Manager) in the
  APOLLO_KEY environment variable and set the experimental_schemaReporting
  option to true in the Apollo Server constructor options, like so:

  const server = new ApolloServer({
    typeDefs,
    resolvers,
    engine: {
      experimental_schemaReporting: true,
      /* Other existing options can remain the same. */
    },
  });

  When enabled, a schema reporter is initiated by the apollo-engine-reporting agent. It will loop until the ApolloServer instance is stopped, periodically calling back to Apollo Graph Manager to send information. The life-cycle of this reporter is managed by the agent.

  For more details on the implementation of this new protocol, see the PR which
  introduced it to Apollo Server and the preview documentation.

  PR #​4084

• apollo-engine-reporting: The underlying integration of this plugin, which instruments and traces the graph's resolver performance and transmits these metrics to Apollo Graph Manager, has been changed from the (soon to be deprecated) graphql-extensions API to the new request pipeline plugins API. PR #​3998

  This change should be purely an implementation detail for a majority of users. There are, however, some special considerations which are worth noting:

  • The federated tracing plugin's ftv1 response on extensions (which is present on the response from an implementing service to the gateway) is now placed on the extensions after the formatResponse hook. Anyone leveraging the extensions.ftv1 data from the formatResponse hook will find that it is no longer present at that phase.

• apollo-tracing: This package's internal integration with Apollo Server has been switched from using the soon-to-be-deprecated graphql-extensions API to using the request pipeline plugin API. Behavior should remain otherwise the same. PR #​3991

• apollo-cache-control: This package's internal integration with Apollo Server has been switched from using the soon-to-be-deprecated graphql-extensions API to using the request pipeline plugin API. Behavior should remain otherwise the same. PR #​3997

v2.13.1

Compare Source

v2.13.0

Compare Source

See complete versioning details.

• Allow passing a WebSocket.Server to ApolloServer.installSubscriptionHandlers. PR #​2314
• apollo-server-lambda: Support file uploads on AWS Lambda Issue #​1419 Issue #​1703 PR #​3926
• apollo-engine-reporting: Fix inadvertant conditional formatting which prevented automated persisted query (APQ) hits and misses from being reported to Apollo Graph Manager. PR #​3986
• apollo-engine-reporting: Deprecate the ENGINE_API_KEY environment variable in favor of its new name, APOLLO_KEY. Continued use of ENGINE_API_KEY will result in deprecation warnings and support for it will be removed in a future major version. #​3923
• apollo-engine-reporting: Deprecated the APOLLO_SCHEMA_TAG environment variable in favor of its new name, APOLLO_GRAPH_VARIANT. Similarly, within the engine configuration object, the schemaTag property has been renamed graphVariant. The functionality remains otherwise unchanged, but their new names mirror the name used within Apollo Graph Manager. Continued use of the now-deprecated names will result in deprecation warnings and support will be dropped completely in the next "major" update. To avoid misconfiguration, a runtime error will be thrown if both new and deprecated names are set. PR #​3855
• apollo-engine-reporting-protobuf: (This is a breaking change only if you directly depend on apollo-engine-reporting-protobuf.) Drop legacy fields that were never used by apollo-engine-reporting. Added new fields StatsContext to allow apollo-server to send summary stats instead of full traces, and renamed FullTracesReport to Report and Traces to TracesAndStats since reports now can include stats as well as traces.

v2.12.0

Compare Source

See complete versioning details.

• apollo-server-core: Support providing a custom logger implementation (e.g. winston, bunyan, etc.) to capture server console messages. Though there has historically been limited output from Apollo Server, some messages are important to capture in the larger context of production logging facilities or can benefit from using more advanced structure, like JSON-based logging. This also introduces a logger property to the GraphQLRequestContext that is exposed to plugins, making it possible for plugins to leverage the same server-level logger, and allowing implementors to create request-specific log contexts, if desired. When not provided, these will still output to console. PR #​3894
• apollo-server-core: When operating in gateway mode using the gateway property of the Apollo Server constructor options, the failure to initialize a schema during initial start-up, e.g. connectivity problems, will no longer result in the federated executor from being assigned when the schema eventually becomes available. This precludes a state where the gateway may never become available to serve federated requests, even when failure conditions are no longer present. PR #​3811
• apollo-server-core: Prevent a condition which prefixed an error message on each request when the initial gateway initialization resulted in a Promise-rejection which was memoized and re-prepended with Invalid options provided to ApolloServer: on each request. PR #​3811
• apollo-server-express: Disable the automatic inclusion of the x-powered-by: express header. PR #​3821
• apollo-engine-reporting: Avoid creating new arrays when building trace trees. PR #​3479
• apollo-server-core: Bump graphql peerDependencies range to include ^15.0.0. PR #​3944

---

Configuration

📅 Schedule: "every weekend" (UTC).

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻️ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.

---

• If you want to rebase/retry this PR, check this box.

---

This PR has been generated by WhiteSource Renovate. View repository job log here.