Update dependency apollo-server-micro to v3

This PR contains the following updates:

Package	Change	Age	Adoption	Passing	Confidence
apollo-server-micro	`^2.19.0` -> `^3.0.0`

Release Notes

apollographql/apollo-server

### [`v3.0.1`](https://togithub.com/apollographql/apollo-server/blob/master/CHANGELOG.md#v301) [Compare Source](https://togithub.com/apollographql/apollo-server/compare/bcfd36cdd01f9d26d0a225aa62a79c6642cd743f...856f7fbc151ebef4d6ca8a9efe801ecca3d4f9c3) - `apollo-server-core`: The default `maxAge` (which defaults to 0) for a field should only be applied if no dynamic cache control hint is set. Specifically, if you call the (new in 3.0.0) function `info.cacheControl.cacheHint.restrict({ maxAge: 60 })`, it should set `maxAge` to 60 even if the default max age is lower. (This bug fix is the behavior that was intended for 3.0.0, and primarily affects the behavior of functions added in Apollo Server 3. This does mean that checking `info.cacheControl.cacheHint` now only shows explicitly-set `maxAge` and not the default, but this seems like it will be helpful since it lets you differentiate between the two similar circumstances.) [PR #5492](https://togithub.com/apollographql/apollo-server/pull/5492) - `apollo-server-lambda`: Fix TypeScript types for `context` function. (In 3.0.0, the TS types for the `context` function were accidentally inherited from `apollo-server-express` instead of using the correct Lambda-specific types). [PR #5481](https://togithub.com/apollographql/apollo-server/pull/5481) - `apollo-server-lambda`, `apollo-server-cloud-functions`: Make the default URL path for handling GraphQL be `/` (ie, handle all requests). This is similar to how these packages work in Apollo Server 2. After this change, `apollo-server` and the serverless integrations have a default URL path of `/` (or ignore the path entirely, in the case of `apollo-server-azure-functions`), and the framework integrations have a default URL path of `/graphql`. This is a backwards-incompatible change from 3.0.1 but minimizes the changes from Apollo Server 2 (and this AS3 change was not intended or documented). [PR #5497](https://togithub.com/apollographql/apollo-server/pull/5497) [Issue #5462](https://togithub.com/apollographql/apollo-server/issues/5462) ### [`v3.0.0`](https://togithub.com/apollographql/apollo-server/blob/master/CHANGELOG.md#v300) [Compare Source](https://togithub.com/apollographql/apollo-server/compare/70a431212bd2d07d68c962cb5ded63ecc6a21963...bcfd36cdd01f9d26d0a225aa62a79c6642cd743f) ##### BREAKING CHANGES ##### Bumped dependencies The minimum versions of these dependencies have been bumped to provide an improved foundation for the development of future features. - Dropped support for Node.js v6, v8 and v10. Apollo Server 3.x is being compiled to ES2020, which maps to Node.js 12+. - Note also that we only test Apollo Server on *even-numbered* versions of Node.js, and we only aim to support Node.js versions that are under [long-term support](https://nodejs.org/en/about/releases/#releases) from the Node.js Foundation. - Dropped support for versions of the `graphql` library prior to `15.3.0`. - The `mocks` option of the `ApolloServer` constructor now uses `@graphql-tools/mock` v7 instead of `graphql-tools` v4, which causes some [breaking changes](https://www.graphql-tools.com/docs/mocking#migration-from-v7-and-below). - For example, mock functions no longer receive arguments and cannot return `Promise`s. - Note that some parts of the v7 migration guide suggest using the `resolvers` argument to `addMocksToSchema`. Apollo Server does not support this option, but you can call `addMocksToSchema` yourself and pass the result to the `schema` option of the `ApolloServer` constructor. ##### Removed functionality Certain undersupported and underused Apollo Server features have been removed in favor of current or future methods for achieving similar functionality. Many of these features can be manually re-enabled, as listed below. - Dropped built-in partial support for subscriptions via the `subscriptions-transport-ws` package. - This integration did not support many Apollo Server features, and `subscriptions-transport-ws` has not been actively maintained. - To re-enable subscriptions in Apollo Server 3 as they're supported in v2, [see the migration guide](./docs/source/migration.mdx#Subscriptions). - We hope to provide more deeply integrated subscription support in a future release. - Dropped built-in support for file uploads via the `graphql-upload` package. - To re-enable file uploads in Apollo Server 3 as they're supported in v2, [see the migration guide](./docs/source/migration.mdx#File-uploads). - Dropped support for the `graphql-extensions` API (e.g., `GraphQLExtensions`, `extensions`) in favor of the Apollo Server [plugins API](https://www.apollographql.com/docs/apollo-server/integrations/plugins/). - Dropped support for passing the `schemaDirectives` option to the `ApolloServer` constructor. - This option was passed directly to the `graphql-tools` function `makeExecutableSchema`. To continue using it, you can import `makeExecutableSchema` from `@graphql-tools/schema` and call it yourself: new ApolloServer({ schema: makeExecutableSchema({ typeDefs, resolvers, schemaDirectives }) }) Note that `graphql-tools` calls this feature ["legacy" schema directives](https://www.graphql-tools.com/docs/legacy-schema-directives/), and you might want to consider the newer [`schemaTransforms`](https://www.graphql-tools.com/docs/schema-directives/) option instead. - Removed the deprecated `ApolloServer.schema` field, which never worked with federated gateways. - To extract your schema from your server, you can make a plugin with `serverWillStart` or register `onSchemaChange` on your gateway. - `apollo-datasource-rest`: We no longer officially support overriding the `baseURL` property with a getter, because TypeScript 4 does not allow you to do so. - Removed the automatic addition of the `@cacheControl` directive to schemas. - This directive was added in some circumstances but not in others, which caused confusion. - If you use `@cacheControl`, you can [define it in your schema as shown in the docs](https://www.apollographql.com/docs/apollo-server/performance/caching/#in-your-schema-static). - Removed the `tracing` option passed to the `ApolloServer` constructor. The corresponding `apollo-tracing` package has been deprecated and is no longer being published. - This package implemented an inefficient JSON format for execution traces returned via the `tracing` GraphQL response extension. This format was only consumed by the deprecated `engineproxy` and GraphQL Playground. - If you rely on this trace format, the old version of `apollo-tracing` should still work: new ApolloServer({ plugins: [ require('apollo-tracing').plugin() ] }); - Removed a redundant mechanism for applying extensions to an `ApolloError`. - Applied extensions are now available only on `error.extensions`, and are not *also* available on `error` itself. - For details, see [#5294](https://togithub.com/apollographql/apollo-server/pull/5294). - Relatedly, the `ForbiddenError` and `AuthenticationError` constructors now allow you to pass additional extensions. - Removed the `cacheControl` option passed to the `ApolloServer` constructor. - By default, Apollo Server continues to calculate an overall cache policy for each operation and sets the `Cache-Control` HTTP header. However, this is now implemented directly inside `apollo-server-core` instead of inside a separate `apollo-cache-control` package (this package has been deprecated and is no longer being published). - Setting cache control options like `defaultMaxAge` is now done via the newly exported `ApolloServerPluginCacheControl` plugin, instead of as a top-level constructor option. This follows the same pattern as other built-in plugins like usage reporting. - The `CacheHint` and `CacheScope` types are now exported from `apollo-server-types`. The `info.cacheControl.cacheHint` object now has additional methods (`replace`, `restrict`, and `policyIfCacheable`), and its fields update when those methods or `setCacheHint` are called. These methods also exist on `requestContext.overallCachePolicy`, which is always defined and which should not be overwritten (use `replace` instead). There is also a new function `info.cacheControl.cacheHintFromType` available. - `@cacheControl` directives on type extensions are no longer ignored. Fields returning union types are now treated similarly to fields returning object and interface types (`@cacheControl` directives on the type are honored, the default `maxAge` is applied to them). - New feature: `@cacheControl(inheritMaxAge: true)` when applied to a composite type or a field returning a composite type means that the default `maxAge` is not applied to that field (unless it is a root field). - Due to conflicts with same/similar globals provided by `@types/supertest` (which we use in our testing), some global TypeScript definitions have been removed from `apollo-server-env` including that of, e.g., `fetch`, `RequestInfo`, `Headers`, `Request`, `Response`, `ResponseInit`, and more. [See the full list prior to removal here](https://togithub.com/apollographql/apollo-server/blob/32cfdcfdbd44f4f4e826f347f47fdcbc0475b5cc/packages/apollo-server-env/src/global.d.ts). Internally in the Apollo Server tests, for the time-being, we are relying on the same-named types from TypeScript's `lib.dom.d.ts` — e.g., [its `RequestInfo` type definition](https://togithub.com/microsoft/TypeScript/blob/3c604f1c0a412ef41f58c3f9b239b25e8d725751/lib/lib.dom.d.ts#L1470). For more details, [see PR #5165](https://togithub.com/apollographql/apollo-server/pull/5165). - Top-level exports have changed. For example: - We no longer re-export the entirety of `graphql-tools` (including `makeExecutableSchema`) from all Apollo Server packages. To continue using them, install [`graphql-tools`](https://www.graphql-tools.com/) or one of its sub-packages yourself. - The `Upload` scalar is no longer exported as part of dropping built-in support for file uploads. - Stopped publishing the deprecated `apollo-server-testing` package. This package is just a wrapper around `server.executeOperation`, which you can use directly. - `apollo-server-caching`: The test suite helper works differently, and the `TestableKeyValueCache` interface is removed. - The `engine` constructor option, `ENGINE_API_KEY` environment variable, and `ENGINE_SCHEMA_TAG` environment variables are no longer supported. Use the `apollo` constructor option, `APOLLO_KEY` environment variable, and `APOLLO_GRAPH_VARIANT` environment variable instead, as described in \[the `engine` option migration guide from v2.18)\[https://www.apollographql.com/docs/apollo-server/v2/migration-engine-plugins/]. ##### Modified functionality - With one exception, all Apollo Server plugin methods (`requestDidStart`, `didResolveOperation`, etc.) are now `async`. - Previously, some of these methods were synchronous, others were `async`, and some were "sometimes-`async`" by returning a `ValueOrPromise`. - The exception is `willResolveField`, which remains synchronous. This method is called much more often than any other plugin method, and converting it to `async` might affect performance. - In a future release, `willResolveField` might become "sometimes-`async`" by returning a `ValueOrPromise`. - Apollo Server now always fires the `willSendResponse` plugin lifecycle event after firing `didEncounterError`. - In certain error cases (mostly related to automated persisted queries), Apollo Server 2 skips firing `willSendResponse`. - Renamed the `GraphQLService` interface to `GatewayInterface`. - This interface is the type used to provide a federated gateway instance to Apollo Server. Its name has been changed to reduce ambiguity. - The previous name is still exported for backward compatibility purposes. - Added support for serving a custom landing page at Apollo Server's base URL. - Plugins can define a new `renderLandingPage` hook that returns an HTML page to serve to browsers. - New plugins (`ApolloServerPluginLandingPageProductionDefault` and `ApolloServerPluginLandingPageLocalDefault`) are installed by default (the former when `NODE_ENV` is `production`, the latter otherwise) with instructions on how to communicate with the server, links to Apollo Sandbox, etc. - A new `ApolloServerPluginLandingPageGraphQLPlayground` plugin can be installed instead to continue to use GraphQL Playground instead. The `playground` option provided to the `ApolloServer` constructor has been removed; to customize GraphQL Playground you can provide an argument to the new playground plugin. By default, no GraphQL Playground settings are overridden, including the endpoint, which now defaults to `window.location.href` (with most query parameters removed). This means you typically don't have to manually configure the endpoint when using GraphQL Playground. - To disable all landing pages, install the new `ApolloServerPluginLandingPageDisabled` plugin. - Apollo Server packages no longer export `defaultPlaygroundOptions`, `PlaygroundConfig`, or `PlaygroundRenderPageOptions`. - Bad request errors (invalid JSON, missing body, etc) are more consistent across integrations and consistently return 4xx status codes instead of sometimes returning 5xx status codes. - Setting `requestContext.response.http.status` now affects successful GraphQL responses, not just errors. ##### Changes to Node.js framework integrations - When using a non-serverless framework integration (Express, Fastify, Hapi, Koa, Micro, or Cloudflare), you now *must* call `await server.start()` before attaching the server to your framework. - This method was introduced in v2.22 but was optional prior to Apollo Server 3. - This requirement does not apply to the `apollo-server` library or to *serverless* framework integrations. - `apollo-server-express` no longer officially supports using with the `connect` framework. - We have not actively removed any `connect` compatibility code, and we do still test that it works with `connect`. However, we reserve the right to break that compatibility without a major version bump of this package (we will certainly note in this changelog if we do so). - `apollo-server-lambda`: This package is now implemented as a wrapper around `apollo-server-express`. `createHandler`'s argument now has different options: - `expressGetMiddlewareOptions`, which includes options like `cors` and is passed through to `apollo-server-express`'s `getMiddleware` - `expressAppFromMiddleware`, which lets you customize HTTP processing Also, the `context` function now receives an `express: { req, res }` option in addition to `event` and `context` - `apollo-server-lambda`: The handler returned by `createHandler` can now only be called as an async function returning a `Promise` (it no longer optionally accepts a callback as the third argument). - All current Lambda Node runtimes support this invocation mode (so `exports.handler = server.createHandler()` will keep working without any changes). - If you've written your *own* handler that calls the handler returned by `createHandler` with a callback, you'll need to handle its `Promise` return value instead. - `apollo-server-lambda`: Improved support for running behind an Application Load Balancer (ALB). - `apollo-server-fastify` is now compatible with Fastify v3 instead of Fastify v2. - `apollo-server-hapi` is now only tested with Hapi v20.1.2 and higher (the minimum version that supports Node 16). - The non-serverless integrations now depend on their corresponding web frameworks via peer dependencies rather than direct dependencies. - All integrations that allow CORS headers to be customized now default to `access-control-allow-origin: *`. This was already the case for `apollo-server`, Express, Fastify, and Hapi; it is now also the same for Koa (which previously reflected the request's origin), Lambda, Cloud Functions, and Azure Functions as well (which did not set CORS by default). Micro and CloudFlare do not have a built-in way of setting CORS headers. ### [`v2.25.2`](https://togithub.com/apollographql/apollo-server/blob/master/CHANGELOG.md#v2252) [Compare Source](https://togithub.com/apollographql/apollo-server/compare/f47c11d3f40f87797c5a615af0bd0225fb18fda8...70a431212bd2d07d68c962cb5ded63ecc6a21963) - `apollo-server-express`: Update dependencies on `@types/express` and `@types/express-serve-static-core`. [PR #5352](https://togithub.com/apollographql/apollo-server/pull/5352) ### [`v2.25.1`](https://togithub.com/apollographql/apollo-server/blob/master/CHANGELOG.md#v2251) [Compare Source](https://togithub.com/apollographql/apollo-server/compare/42983b06a381aee6333fd11d5af7bd7fa0d549ec...f47c11d3f40f87797c5a615af0bd0225fb18fda8) - `apollo-server-core`, `apollo-server-express`: Upgrade `subscriptions-transport-ws` dependency and remove unneeded runtime dependency on `ws`. This should enable you to install Apollo Server without depending on versions of `ws` vulnerable to [CVE-2021-32640](https://www.npmjs.com/advisories/1748). Note that the superficial integration of the unmaintained `subscriptions-transport-ws` package will be removed in Apollo Server 3; you can also avoid this vulnerability by disabling the built-in subscription support with `new ApolloServer({subscriptions: false})` and using a maintained package such as `graphql-ws` instead. (Instead of taking this upgrade, you can also upgrade `ws` to `5.2.3`, which was just released.) ### [`v2.25.0`](https://togithub.com/apollographql/apollo-server/blob/master/CHANGELOG.md#v2250) [Compare Source](https://togithub.com/apollographql/apollo-server/compare/9e1bf7df8ce856f62e851a9cf268508eb574e32c...42983b06a381aee6333fd11d5af7bd7fa0d549ec) - `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](https://togithub.com/apollographql/apollo-server/pull/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](https://togithub.com/apollographql/apollo-server/pull/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](https://togithub.com/apollographql/apollo-server/issues/4952) - `apollo-server-testing`: Replace README with a deprecation notice explaining how to use `server.executeOperation` instead. [Issue #4952](https://togithub.com/apollographql/apollo-server/issues/4952) ### [`v2.24.1`](https://togithub.com/apollographql/apollo-server/blob/master/CHANGELOG.md#v2241) [Compare Source](https://togithub.com/apollographql/apollo-server/compare/f2349d0e10633ee79bed152f682e53730175d59b...9e1bf7df8ce856f62e851a9cf268508eb574e32c) - `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](https://togithub.com/apollographql/apollo-server/pull/5149) ### [`v2.24.0`](https://togithub.com/apollographql/apollo-server/blob/master/CHANGELOG.md#v2240) [Compare Source](https://togithub.com/apollographql/apollo-server/compare/8a4cc583b692a30670d1893c01851259dbd70ce1...f2349d0e10633ee79bed152f682e53730175d59b) - `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](https://togithub.com/apollographql/apollo-server/pull/4142) ### [`v2.23.0`](https://togithub.com/apollographql/apollo-server/blob/master/CHANGELOG.md#v2230) [Compare Source](https://togithub.com/apollographql/apollo-server/compare/9562af498407e86923d96902683bb5285b849800...8a4cc583b692a30670d1893c01851259dbd70ce1) - `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](https://togithub.com/apollographql/apollo-server/pull/4166) [Issue #2886](https://togithub.com/apollographql/apollo-server/issues/2886) - `apollo-server-cache-redis@1.4.0`: 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](https://togithub.com/apollographql/apollo-server/pull/5034) [PR #5088](https://togithub.com/apollographql/apollo-server/pull/5088) [Issue #4870](https://togithub.com/apollographql/apollo-server/issues/4870) [Issue #5006](https://togithub.com/apollographql/apollo-server/issues/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](https://togithub.com/apollographql/apollo-server/issues/5009) [PR #5089](https://togithub.com/apollographql/apollo-server/pull/5089) - `apollo-server-lambda`: Fix regression in v2.21.2 where thrown errors were replaced by throwing the JS Error class itself. [PR #5085](https://togithub.com/apollographql/apollo-server/pull/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](https://togithub.com/apollographql/apollo-server/pull/5091) [Issue #3498](https://togithub.com/apollographql/apollo-server/issues/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(...)` or `new ApolloServer(...)` (importing these types from `aws-lambda`), or differentiate between the two formats by checking to see if `'path' in event`. [Issue #5084](https://togithub.com/apollographql/apollo-server/issues/5084) [Issue #5016](https://togithub.com/apollographql/apollo-server/issues/5016) ### [`v2.22.2`](https://togithub.com/apollographql/apollo-server/blob/master/CHANGELOG.md#v2222) [Compare Source](https://togithub.com/apollographql/apollo-server/compare/6ad8f8f8ce743553d99097f77aeb7fdd4a536e7c...9562af498407e86923d96902683bb5285b849800) - `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](https://togithub.com/apollographql/apollo-server/issues/5065) [Issue #5066](https://togithub.com/apollographql/apollo-server/issues/5066) [PR #5073](https://togithub.com/apollographql/apollo-server/pull/5073) ### [`v2.22.1`](https://togithub.com/apollographql/apollo-server/blob/master/CHANGELOG.md#v2221) [Compare Source](https://togithub.com/apollographql/apollo-server/compare/93499e703a375ff0fbd128138e46b574074b44e6...6ad8f8f8ce743553d99097f77aeb7fdd4a536e7c) - `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](https://togithub.com/apollographql/apollo-server/pull/5064) ### [`v2.22.0`](https://togithub.com/apollographql/apollo-server/blob/master/CHANGELOG.md#v2220) [Compare Source](https://togithub.com/apollographql/apollo-server/compare/7d3593d2c27be2a74cba4adfb57894856d8fac81...93499e703a375ff0fbd128138e46b574074b44e6) - 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()`](https://www.apollographql.com/docs/apollo-server/api/apollo-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](https://togithub.com/apollographql/apollo-server/pull/4981) ### [`v2.21.2`](https://togithub.com/apollographql/apollo-server/blob/master/CHANGELOG.md#v2212) [Compare Source](https://togithub.com/apollographql/apollo-server/compare/9941c8f027cc8fce6a15f8678629fdc5dab4c2d0...7d3593d2c27be2a74cba4adfb57894856d8fac81) - `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](https://togithub.com/apollographql/apollo-server/issues/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](https://docs.aws.amazon.com/lambda/latest/dg/nodejs-handler.html#nodejs-handler-async) 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](https://togithub.com/apollographql/apollo-server/issues/1989) [PR #5004](https://togithub.com/apollographql/apollo-server/pull/5004) ### [`v2.21.1`](https://togithub.com/apollographql/apollo-server/blob/master/CHANGELOG.md#v2211) [Compare Source](https://togithub.com/apollographql/apollo-server/compare/456487f425d3504c1b1425cbb7c954c664b0631e...9941c8f027cc8fce6a15f8678629fdc5dab4c2d0) - `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](https://togithub.com/apollographql/apollo-server/issues/3999) [PR #4969](https://togithub.com/apollographql/apollo-server/pull/4969) [Issue #4891](https://togithub.com/apollographql/apollo-server/issues/4891) [PR #4892](https://togithub.com/apollographql/apollo-server/pull/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](https://togithub.com/apollographql/apollo-server/issues/4107) [PR #4948](https://togithub.com/apollographql/apollo-server/pull/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](https://togithub.com/apollographql/apollo-server/pull/4932) [PR #4955](https://togithub.com/apollographql/apollo-server/pull/4955) [Issue #4937](https://togithub.com/apollographql/apollo-server/issues/4937) ### [`v2.21.0`](https://togithub.com/apollographql/apollo-server/blob/master/CHANGELOG.md#v2210) [Compare Source](https://togithub.com/apollographql/apollo-server/compare/baf9b252dfab150ec828ef83345a7ceb2d34a6a3...456487f425d3504c1b1425cbb7c954c664b0631e) - Apollo Server can now be installed with `graphql@15` without causing peer dependency errors or warnings. (Apollo Server has a [file upload](https://www.apollographql.com/docs/apollo-server/data/file-uploads/) 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](https://togithub.com/apollographql/apollo-server/issues/4865) ### [`v2.20.0`](https://togithub.com/apollographql/apollo-server/blob/master/CHANGELOG.md#v2200) [Compare Source](https://togithub.com/apollographql/apollo-server/compare/c212627be591cd2c2469321b58b15f1b7909778d...baf9b252dfab150ec828ef83345a7ceb2d34a6a3) - `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](https://togithub.com/apollographql/apollo-server/pull/4908) [Issue #4097](https://togithub.com/apollographql/apollo-server/issues/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](https://togithub.com/apollographql/apollo-server/pull/4907) [Issue #4428](https://togithub.com/apollographql/apollo-server/issues/4428) - `apollo-server-core`: Avoid instrumenting schemas for the old `graphql-extensions` library unless extensions are provided. [PR #4893](https://togithub.com/apollographql/apollo-server/pull/4893) [Issue #4889](https://togithub.com/apollographql/apollo-server/issues/4889) - `apollo-server-plugin-response-cache@0.6.0`: The `shouldReadFromCache` and `shouldWriteToCache` hooks were always documented as returning `ValueOrPromise` (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](https://togithub.com/apollographql/apollo-server/pull/4890) [Issue #4886](https://togithub.com/apollographql/apollo-server/issues/4886) - `apollo-datasource-rest@0.10.0`: The `RESTDataSource.trace` method is now `protected` instead of `private` to allow more control over logging and metrics. [PR #3940](https://togithub.com/apollographql/apollo-server/pull/3940) ### [`v2.19.2`](https://togithub.com/apollographql/apollo-server/blob/master/CHANGELOG.md#v2192) [Compare Source](https://togithub.com/apollographql/apollo-server/compare/7e543ed5540ce5995b30b1bb2a7b54367fd49d6f...c212627be591cd2c2469321b58b15f1b7909778d) - `apollo-server-express`: types: Export `ExpressContext` from main module. [PR #4821](https://togithub.com/apollographql/apollo-server/pull/4821) [Issue #3699](https://togithub.com/apollographql/apollo-server/issues/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](https://togithub.com/apollographql/apollo-server/pull/4822) [Issue #4741](https://togithub.com/apollographql/apollo-server/issues/4741) - `apollo-server-core`: Update `graphql-tag` package to `latest`, now with its `graphql-js` `peerDependencies` expanded to include `^15.0.0` [PR #4833](https://togithub.com/apollographql/apollo-server/pull/4833) ### [`v2.19.1`](https://togithub.com/apollographql/apollo-server/blob/master/CHANGELOG.md#v2191) [Compare Source](https://togithub.com/apollographql/apollo-server/compare/4c6d16f14ab735ba0361057d75e51adb6790426c...7e543ed5540ce5995b30b1bb2a7b54367fd49d6f) - `apollo-server-core`: The `debugPrintReports` option to `ApolloServerPluginUsageReporting` now prints traces as well. [PR #4805](https://togithub.com/apollographql/apollo-server/pull/4805)

Configuration

📅 Schedule: At any time (no schedule defined).

🚦 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.

module-federation / federation-dashboard

Update dependency apollo-server-micro to v3 #298

Release Notes

Configuration

⚠️ No Changeset found

Renovate Ignore Notification