search

caioagiani / nestjs-graphql

NestJS API GraphQL
5 stars 1 forks source link

fix(deps): update dependency apollo-server-express to v3 #21

Closed renovate[bot] closed 2 years ago

renovate[bot] commented 3 years ago

WhiteSource Renovate

This PR contains the following updates:

Package Change Age Adoption Passing Confidence
apollo-server-express 2.25.2 -> 3.6.3 age adoption passing confidence

Release Notes

apollographql/apollo-server ### [`v3.6.3`](https://togithub.com/apollographql/apollo-server/blob/HEAD/CHANGELOG.md#v363) [Compare Source](https://togithub.com/apollographql/apollo-server/compare/022184a4d01d4452ebbcfeeef6e8ee1aae7a5db7...289acad0e3777bd0010506763c3fd6e4c0289813) - `apollo-server-core`: The inline trace plugin will now include the full query plan and subgraph traces if manually installed in an Apollo Gateway. (Previously, you technically could install this plugin in a Gateway but it would not have any real trace data.) This is recommended for development use only and not in production servers. [PR #​6017](https://togithub.com/apollographql/apollo-server/pull/6017) - `apollo-server-core`: The default landing page plugins now take an `includeCookies` option which allows you to specify that Explorer should send cookies to your server. [PR #​6014](https://togithub.com/apollographql/apollo-server/pull/6014) - `apollo-server-core`: Apollo Server has a heuristic added in v2.23.0 and improved in v3.1.0 which tries to detect execution errors that come from the `graphql-js` variable value validation phase and report them with an `extensions.code` of `BAD_USER_INPUT` rather than `INTERNAL_SERVER_ERROR`. In this release, the heuristic is improved to include some cases including variables that are non-null lists. [PR #​6066](https://togithub.com/apollographql/apollo-server/pull/6066) ### [`v3.6.2`](https://togithub.com/apollographql/apollo-server/blob/HEAD/CHANGELOG.md#v362) [Compare Source](https://togithub.com/apollographql/apollo-server/compare/f3fc7d147a3bc3446f4f3452acfa5f598099b08f...022184a4d01d4452ebbcfeeef6e8ee1aae7a5db7) - ⚠️ **SECURITY** `apollo-server-env`: Update dependency on `node-fetch` to require v2.6.7 rather than v2.6.1. This includes the fix to [CVE-2022-0235](https://nvd.nist.gov/vuln/detail/CVE-2022-0235), a vulnerability where credentials sent along with a request could be sent to a different origin if the fetched URL responds with an attacker-controlled HTTP redirect. This is the default fetcher used by `apollo-datasource-rest`, usage reporting, schema reporting, and `@apollo/gateway` in versions prior to v0.46.0. We do not believe that the way that this is used by usage reporting or schema reporting is vulnerable to the exploit, but if you use `apollo-datasource-rest` in such a way that the servers you talk to might serve a surprising redirect, this upgrade would be helpful. Note that to ensure you're using the appropriate version of `apollo-server-env` with `apollo-datasource-rest`, you need to be using v3.5.1 of that package. (We plan to separate the release process of `apollo-datasource-rest` from Apollo Server soon so that it can have a more reasonable changelog.) If upgrading to this version is challenging, you can also work around this by ensuring that `node-fetch@2.6.7` is the version used in your project, or by specifying a `fetcher` explicitly to your older Gateway, REST datasource, etc. - `apollo-server-core`: The `typeDefs`, `resolvers`, and `parseOptions` constructor arguments are passed directly through to `makeExecutableSchema` from `@graphql-tools/schema` if provided. Now their TypeScript type definitions come directly from that package so that any types accepted by that package can be provided. [PR #​5978](https://togithub.com/apollographql/apollo-server/pull/5978) - `apollo-server-fastify`: Drop dependency on `fast-json-stringify`. [PR #​5988](https://togithub.com/apollographql/apollo-server/pull/5988) - `apollo-server-azure-functions`: Update TypeScript types package `@azure/functions` from v1 to v3 and change it to a dev dependency. (We were advised to change it to a dev dependency [by the authors of the package](https://togithub.com/Azure/azure-functions-nodejs-worker/pull/467#issuecomment-967737890); if this turns out to be problematic we can revert this part of the change. They also do not believe this is a backwards-incompatible change despite the major version bump; this package does a major version bump when the underlying Azure Functions runtime has a major version bump.) [PR #​5919](https://togithub.com/apollographql/apollo-server/pull/5919) ### [`v3.6.1`](https://togithub.com/apollographql/apollo-server/blob/HEAD/CHANGELOG.md#v361) [Compare Source](https://togithub.com/apollographql/apollo-server/compare/8b2c1360c224d23ff64fa49adbee1e62dbdaa917...f3fc7d147a3bc3446f4f3452acfa5f598099b08f) - Correctly remove dependency on `apollo-graphql` as intended in v3.6.0. [Issue #​5981](https://togithub.com/apollographql/apollo-server/issues/5981) [PR #​5981](https://togithub.com/apollographql/apollo-server/pull/5981) ### [`v3.6.0`](https://togithub.com/apollographql/apollo-server/blob/HEAD/CHANGELOG.md#v360) [Compare Source](https://togithub.com/apollographql/apollo-server/compare/e6c3cbbf820b3ffff1e7e98d41b3bfc08f99b9b0...8b2c1360c224d23ff64fa49adbee1e62dbdaa917) - `apollo-server-core`: Studio usage reporting now reports "referenced operations" for fields in addition to "field executions", which can be seen on the Studio Fields page. This new statistic provides visibility into uses of fields that are not executed. It is also more efficient to generate and (for Apollo Gateways) does not require subgraphs to support federated tracing. Additionally, the new `fieldLevelInstrumentation` option to `ApolloServerPluginUsageReporting` allows you to disable field-level tracing on a per-operation basis, and to report weights for operations to allow for estimates of the field execution count even when not all operations are instrumented. Note that the semantics of the `requestContext.metrics.captureTraces` field have changed. See the [Studio Fields page docs](https://www.apollographql.com/docs/studio/metrics/field-usage/) and the [`fieldLevelInstrumentation` docs](https://www.apollographql.com/docs/apollo-server/api/plugin/usage-reporting/#fieldlevelinstrumentation) for more details. [Issue #​5708](https://togithub.com/apollographql/apollo-server/issues/5708) [PR #​5956](https://togithub.com/apollographql/apollo-server/pull/5956) [PR #​5963](https://togithub.com/apollographql/apollo-server/pull/5963) - `apollo-server-core`: Usage reporting no longer sends a "client reference ID" to Apollo Studio (along with the client name and client version). This little-used feature has not been documented [since 2019](https://togithub.com/apollographql/apollo-server/pull/3180) and is currently entirely ignored by Apollo Studio. This is technically incompatible as the interface `ClientInfo` no longer has the field `clientReferenceId`; if you were one of the few users who explicitly set this field and you get a TypeScript compilation failure upon upgrading to v3.6.0, just stop using the field. [PR #​5890](https://togithub.com/apollographql/apollo-server/pull/5890) - `apollo-server-core`: Remove dependency on `apollo-graphql` package (by inlining the code which generates usage reporting signatures). That package has not yet been published with a `graphql@16` peer dependency, so Apollo Server v3.5 did not fully support `graphql@16` without overriding peer dependencies. [Issue #​5941](https://togithub.com/apollographql/apollo-server/issues/5941) [PR #​5955](https://togithub.com/apollographql/apollo-server/pull/5955) ### [`v3.5.0`](https://togithub.com/apollographql/apollo-server/blob/HEAD/CHANGELOG.md#v350) [Compare Source](https://togithub.com/apollographql/apollo-server/compare/f3fcbfe09957806df06f8de431877dd39d8b97c0...e6c3cbbf820b3ffff1e7e98d41b3bfc08f99b9b0) - Apollo Server now supports `graphql@16`. (There is a very small backwards incompatibility: `ApolloError.originalError` can no longer be `null`, matching the type of `GraphQLError.originalError`. Use `undefined` instead. If this causes challenges, let us know and we can try to adapt.) [PR #​5857](https://togithub.com/apollographql/apollo-server/pull/5857) \- `apollo-server-core`: Fix build error when building with `@rollup/plugin-commonjs`. [PR #​5797](https://togithub.com/apollographql/apollo-server/pull/5797) - `apollo-server-plugin-response-cache`: Add missing dependency on `apollo-server-types` (broken since v3.0.0). [Issue #​5804](https://togithub.com/apollographql/apollo-server/issues/5804) [PR #​5816](https://togithub.com/apollographql/apollo-server/pull/5816) - `apollo-server-core`: The default landing page plugins now take `document`, `variables`, and `headers` arguments which fill in default values if you click through to Explorer. [PR #​5711](https://togithub.com/apollographql/apollo-server/pull/5711) - `apollo-server-core`: Support for HTTP request batching can now be disabled by passing `allowBatchedHttpRequests: false` to `new ApolloServer`. [PR #​5778](https://togithub.com/apollographql/apollo-server/pull/5778) [Issue #​5686](https://togithub.com/apollographql/apollo-server/issues/5686) ### [`v3.4.1`](https://togithub.com/apollographql/apollo-server/blob/HEAD/CHANGELOG.md#v341) [Compare Source](https://togithub.com/apollographql/apollo-server/compare/7861ba22c9e4caf037e7a1cec71191b9b0deb71b...f3fcbfe09957806df06f8de431877dd39d8b97c0) - ⚠️ **SECURITY** `apollo-server-core`: Update default version of the GraphQL Playground React app loaded from the CDN to be `@apollographql/graphql-playground-react@1.7.42`. This patches an XSS vulnerability. Note that if you are pinning the Playground React app version in your app with `new ApolloServer({plugins: [ApolloServerPluginLandingPageGraphQLPlayground({version: 'some version'})]})`, you will need to update the specified version to 1.7.42 or later to avoid this vulnerability. If you do not explicitly enable GraphQL Playground via the `ApolloServerPluginLandingPageGraphQLPlayground` plugin, this vulnerability does not affect you. See [advisory GHSA-qm7x-rc44-rrqw](https://togithub.com/apollographql/apollo-server/security/advisories/GHSA-qm7x-rc44-rrqw) for more details. ### [`v3.4.0`](https://togithub.com/apollographql/apollo-server/blob/HEAD/CHANGELOG.md#v340) [Compare Source](https://togithub.com/apollographql/apollo-server/compare/8524df3d3fe98b7ad625c48cb393cd4a59ec1476...7861ba22c9e4caf037e7a1cec71191b9b0deb71b) - `apollo-server-core`: You can now specify your own `DocumentStore` (a `KeyValueStore`) for Apollo Server's cache of parsed and validated GraphQL operation abstract syntax trees via the new `documentStore` constructor option. **This replaces the `experimental_approximateDocumentStoreMiB` option.** You can replace `new ApolloServer({experimental_approximateDocumentStoreMiB: approximateDocumentStoreMiB, ...moreOptions})` with: ```typescript import { InMemoryLRUCache } from 'apollo-server-caching'; import type { DocumentNode } from 'graphql'; new ApolloServer({ documentStore: new InMemoryLRUCache({ maxSize: Math.pow(2, 20) * approximateDocumentStoreMiB, sizeCalculator: InMemoryLRUCache.jsonBytesSizeCalculator, }), ...moreOptions, }) ``` [PR #​5644](https://togithub.com/apollographql/apollo-server/pull/5644) [Issue #​5634](https://togithub.com/apollographql/apollo-server/issues/5634) - `apollo-server-core`: For ease of testing, you can specify the node environment via `new ApolloServer({nodeEnv})` in addition to via the `NODE_ENV` environment variable. The environment variable is now only read during server startup (and in some error cases) rather than on every request. [PR #​5657](https://togithub.com/apollographql/apollo-server/pull/5657) - `apollo-server-koa`: The peer dependency on `koa` (added in v3.0.0) should be a `^` range dependency rather than depending on exactly one version, and it should not be automatically increased when new versions of `koa` are released. [PR #​5759](https://togithub.com/apollographql/apollo-server/pull/5759) - `apollo-server-fastify`: Export `ApolloServerFastifyConfig` and `FastifyContext` TypeScript types. [PR #​5743](https://togithub.com/apollographql/apollo-server/pull/5743) - `apollo-server-core`: Only generate the schema hash once on startup rather than twice. [PR #​5757](https://togithub.com/apollographql/apollo-server/pull/5757) - `apollo-datasource-rest@3.3.0`: When choosing whether or not to parse a response as JSON, treat any `content-type` ending in `+json` as JSON rather than just `application/hal+json` (in addition to `application/json`). [PR #​5737](https://togithub.com/apollographql/apollo-server/pull/5737) - `apollo-server`: You can now configure the health check URL path with the `healthCheckPath` constructor option, or disable serving health checks by passing `null` for this option. (This option is specific to the batteries-included `apollo-server` package; if you're using a framework integration package and want to serve a health check at a different path, just use your web framework directly.) [PR #​5270](https://togithub.com/apollographql/apollo-server/pull/5270) [Issue #​3577](https://togithub.com/apollographql/apollo-server/issues/3577) - `apollo-server-azure-functions`: This package now supports health checks like all of the other supported Apollo Server packages; they are on by default and can be customized with `disableHealthCheck` and `onHealthCheck`. \[PR [#​5003](https://togithub.com/apollographql/apollo-server/issues/5003)]\(https://[github.com/apollographql/apollo-server/pull/5003](togithub.com/apollographql/apollo-server/pull/5003)3) [Issue #​4925](https://togithub.com/apollographql/apollo-server/issues/4925) - Tests are no longer distributed inside published npm modules. [PR #​5799](https://togithub.com/apollographql/apollo-server/pull/5799) [Issue #​5781](https://togithub.com/apollographql/apollo-server/issues/5781) ### [`v3.3.0`](https://togithub.com/apollographql/apollo-server/blob/HEAD/CHANGELOG.md#v330) [Compare Source](https://togithub.com/apollographql/apollo-server/compare/4dc19131aaea2416b5b2ccab295b06272f94c996...8524df3d3fe98b7ad625c48cb393cd4a59ec1476) - `apollo-server-core`: Error handling when a `serverWillStop` callback invoked by `server.stop()` (or `gateway.stop()`) throws is now consistent: the original call to `server.stop()` throws the error, and any concurrent and subsequent calls to `server.stop()` throw the same error. Prior to Apollo Server v2.22.0, the original call threw the error and the behavior of concurrent and subsequent calls was undefined (in practice, it would call shutdown handlers a second time). Apollo Server v2.22.0 intended to put these semantics into place where all three kinds of calls would throw, but due to bugs, the original call would return without error and concurrent calls would hang. (Subsequent calls would correctly throw the error.) In addition, errors thrown by the `drainServer` hook introduced in Apollo Server v3.2.0 are now handled in the same way. [Issue #​5649](https://togithub.com/apollographql/apollo-server/issues/5649) [PR #​5653](https://togithub.com/apollographql/apollo-server/pull/5653) ### [`v3.2.0`](https://togithub.com/apollographql/apollo-server/blob/HEAD/CHANGELOG.md#v320) [Compare Source](https://togithub.com/apollographql/apollo-server/compare/65c88f171864ee5bffb95f36aec93120b77bd56b...4dc19131aaea2416b5b2ccab295b06272f94c996) **If you're using `apollo-server-express` or another framework integration**, we highly recommend that you enable the new graceful shutdown feature after upgrading to 3.2.0. See the docs for [`ApolloServerPluginDrainHttpServer`](https://www.apollographql.com/docs/apollo-server/api/plugin/drain-http-server/) or the [basic usage for your integration of choice](https://www.apollographql.com/docs/apollo-server/integrations/middleware/#basic-usage). - `apollo-server-core`: Previously, only the batteries-included `apollo-server` package supported a graceful shutdown. Now the integrations support it as well, if you tell your `ApolloServer` which HTTP server to drain with the new `ApolloServerPluginDrainHttpServer` plugin. This plugin implements a new `drainServer` plugin hook. For `apollo-server-hapi` you can use `ApolloServerPluginStopHapiServer` instead. [PR #​5635](https://togithub.com/apollographql/apollo-server/pull/5635) - `apollo-server-core`: Fix `experimental_approximateDocumentStoreMiB` option, which seems to have never worked before. [PR #​5629](https://togithub.com/apollographql/apollo-server/pull/5629) - `apollo-server-core`: Only register `SIGINT` and `SIGTERM` handlers once the server successfully starts up; trying to call `stop` on a server that hasn't successfully started had undefined behavior. By default, don't register the handlers in serverless integrations, which don't have the same lifecycle as non-serverless integrations (eg, there's no explicit `start` call); you can still explicitly set `stopOnTerminationSignals` to override this default. [PR #​5639](https://togithub.com/apollographql/apollo-server/pull/5639) ### [`v3.1.2`](https://togithub.com/apollographql/apollo-server/blob/HEAD/CHANGELOG.md#v312) [Compare Source](https://togithub.com/apollographql/apollo-server/compare/eb06724ca43042fcbf6e04e1de1dc2e5acfadf33...65c88f171864ee5bffb95f36aec93120b77bd56b) - `apollo-server-core`: Update versions of `@graphql-tools/schema` and `@graphql-tools/utils` from v7 to v8. While there is no change in behavior in these versions, a recently-released version of `@graphql-tools/mock` depends on them, and so without this change, you typically end up with two copies of them installed. ### [`v3.1.1`](https://togithub.com/apollographql/apollo-server/blob/HEAD/CHANGELOG.md#v311) [Compare Source](https://togithub.com/apollographql/apollo-server/compare/d22ffd33da9fa2972e6d055ebc4b346ad329edff...eb06724ca43042fcbf6e04e1de1dc2e5acfadf33) - `apollo-server-env`: Update `Headers.values()` type to match what `node-fetch` actually does and what the Fetch spec says it should be, and what `@types/node-fetch` [finally](https://togithub.com/DefinitelyTyped/DefinitelyTyped/pull/54674) gets correct. [PR #​5537](https://togithub.com/apollographql/apollo-server/pull/5537) ### [`v3.1.0`](https://togithub.com/apollographql/apollo-server/blob/HEAD/CHANGELOG.md#v310) [Compare Source](https://togithub.com/apollographql/apollo-server/compare/69577df0b08d392e99d65644a27d48b9b925dd94...d22ffd33da9fa2972e6d055ebc4b346ad329edff) - `apollo-server-core`: If a client does not provide a value or provides null for a variable declared to be non-null, this is now reported as an error with an `extensions.code` of `BAD_USER_INPUT` rather than `INTERNAL_SERVER_ERROR`. (This is similar to a change we made in v2.23.0 for variables that are sent as the wrong type.) [PR #​5508](https://togithub.com/apollographql/apollo-server/pull/5508) [Issue #​5353](https://togithub.com/apollographql/apollo-server/issues/5353) - `apollo-server-core`/`apollo-server-plugin-base`: Add support for `schemaDidLoadOrUpdate` event hooks, to be specified by the `serverWillStart` event hook. Plugins listening for this event will receive the API schema (and core schema for gateways) when the server's schema is initially loaded and when the server's schema is updated. For more information about this plugin event, see [the plugin event reference documentation](https://www.apollographql.com/docs/apollo-server/integrations/plugins-event-reference/). [PR #​5187](https://togithub.com/apollographql/apollo-server/pull/5187) - `apollo-server-core`: Add support for schema reporting when using Apollo Gateway. At the time of this package's release, Apollo Studio does not yet support schema reporting from gateways, so you should not use this feature yet for gateways (unless instructed otherwise by Apollo staff or by the Studio docs). If you do enable schema reporting for a gateway, the version of `@apollo/gateway` must be at least `0.35.0` , or else `start()` will error. [PR #​5187](https://togithub.com/apollographql/apollo-server/pull/5187) - `apollo-server-core`: Support gateways without executors, to help with mocking gateways. Note that if you have a custom `GatewayInterface` implementation, Apollo Server will now honor the `executor` returned from `load` and will ignore the `executor` method on the gateway itself. See the PR for details. [PR #​5539](https://togithub.com/apollographql/apollo-server/pull/5539) - `apollo-server-plugin-response-cache`, `apollo-server-plugin-operation-registry`: Change how the default export from the package is set up to fix errors with some build tools. [PR #​5542](https://togithub.com/apollographql/apollo-server/pull/5542) ### [`v3.0.2`](https://togithub.com/apollographql/apollo-server/blob/HEAD/CHANGELOG.md#v302) [Compare Source](https://togithub.com/apollographql/apollo-server/compare/856f7fbc151ebef4d6ca8a9efe801ecca3d4f9c3...69577df0b08d392e99d65644a27d48b9b925dd94) - `apollo-server-types`: TypeScript typings for `info.cacheControl` are now added to `GraphQLResolveInfo` as part of `apollo-server-types` rather than a nested file in `apollo-server-core`, and the field now has a named type, `ResolveInfoCacheControl`. [PR #​5512](https://togithub.com/apollographql/apollo-server/pull/5512) - `apollo-server-micro`: Like the other framework integrations, only serve landing pages from the GraphQL path (`/graphql` by default, configurable via the `path` option to `createHandler`). [PR #​5516](https://togithub.com/apollographql/apollo-server/pull/5516) - `apollo-server-env`: Remove polyfills of `Object.values`, `Object.entries`, and `util.promisify` which were only required for Node 6 support. Remove `ValueOrPromise` and `WithRequired` TypeScript types that are also provided by `apollo-server-types`. [PR #​5515](https://togithub.com/apollographql/apollo-server/pull/5515) ### [`v3.0.1`](https://togithub.com/apollographql/apollo-server/blob/HEAD/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/HEAD/CHANGELOG.md#v300) [Compare Source](https://togithub.com/apollographql/apollo-server/compare/a725306525a99650af46effb72ae9afe780ed88b...bcfd36cdd01f9d26d0a225aa62a79c6642cd743f) ##### BREAKING CHANGES Apollo Server 3 contains quite a few breaking changes. Read our [migration guide](https://www.apollographql.com/docs/apollo-server/migration/) for more details on how to update your app. ##### 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](https://www.apollographql.com/docs/apollo-server/migration/#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](https://www.apollographql.com/docs/apollo-server/migration/#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/]. - When you supply an Apollo API key via the `APOLLO_KEY` environment variable or `new ApolloServer({apollo: {key}})`, Apollo Server 3 no longer parses the key to guess your Studio graph ID. You must specify it yourself, either via the `APOLLO_GRAPH_ID` environment variable (or `new ApolloServer({apollo: {graphId}})`), or as a graph ref along with the variant (e.g., `your-graph-id@your-graph-variant`) in the `APOLLO_GRAPH_REF` environment variable (or `new ApolloServer({apollo: {graphRef}})`). ##### 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`. - The `executionDidStart` event can no longer return a function as an "end hook". The "end hook" for this event now must be provided as an async function property called `executionDidEnd` on an object. - 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.3`](https://togithub.com/apollographql/apollo-server/blob/HEAD/CHANGELOG.md#v2253) [Compare Source](https://togithub.com/apollographql/apollo-server/compare/70a431212bd2d07d68c962cb5ded63ecc6a21963...a725306525a99650af46effb72ae9afe780ed88b) - ⚠️ **SECURITY** `apollo-server-core`: Update default version of the GraphQL Playground React app loaded from the CDN to be `@apollographql/graphql-playground-react@1.7.42`. This patches an XSS vulnerability. Note that if you are pinning the Playground React app version in your app with `new ApolloServer({playground: {version: 'some version'}})`, you will need to update the specified version to 1.7.42 or later to avoid this vulnerability. If you disable GraphQL Playground with `new ApolloServer({playground: false})`, this vulnerability does not affect you. See [advisory GHSA-qm7x-rc44-rrqw](https://togithub.com/apollographql/apollo-server/security/advisories/GHSA-qm7x-rc44-rrqw) for more details.

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.

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

renovate[bot] commented 2 years ago

Renovate Ignore Notification

Because you closed this PR without merging, Renovate will ignore this update. You will not get PRs for any future 3.x releases. But if you manually upgrade to 3.x then Renovate will re-enable minor and patch updates automatically.

If you accidentally closed this PR, or if you changed your mind: rename this PR to get a fresh replacement PR.