chore(deps): bump apollo-server-express from 2.25.2 to 3.6.1

[dependabot]

Bumps apollo-server-express from 2.25.2 to 3.6.1.

Changelog

Sourced from apollo-server-express's changelog.

v3.6.1

• Correctly remove dependency on apollo-graphql as intended in v3.6.0. [Issue #5981](apollographql/apollo-server#5981) [PR #5981](apollographql/apollo-server#5981)

v3.6.0

• 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 and the fieldLevelInstrumentation docs for more details. [Issue #5708](apollographql/apollo-server#5708) [PR #5956](apollographql/apollo-server#5956) [PR #5963](apollographql/apollo-server#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 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](apollographql/apollo-server#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](apollographql/apollo-server#5941) [PR #5955](apollographql/apollo-server#5955)

v3.5.0

• 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](apollographql/apollo-server#5857) - apollo-server-core: Fix build error when building with @rollup/plugin-commonjs. [PR #5797](apollographql/apollo-server#5797)
• apollo-server-plugin-response-cache: Add missing dependency on apollo-server-types (broken since v3.0.0). [Issue #5804](apollographql/apollo-server#5804) [PR #5816](apollographql/apollo-server#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](apollographql/apollo-server#5711)
• apollo-server-core: Support for HTTP request batching can now be disabled by passing allowBatchedHttpRequests: false to new ApolloServer. [PR #5778](apollographql/apollo-server#5778) [Issue #5686](apollographql/apollo-server#5686)

v3.4.1

• ⚠️ SECURITY apollo-server-core: Update default version of the GraphQL Playground React app loaded from the CDN to be @apollographql/[email protected]. 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 for more details.

v3.4.0

• apollo-server-core: You can now specify your own DocumentStore (a KeyValueStore<DocumentNode>) 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:

  import { InMemoryLRUCache } from 'apollo-server-caching';
  import type { DocumentNode } from 'graphql';
  new ApolloServer({
    documentStore: new InMemoryLRUCache<DocumentNode>({
      maxSize: Math.pow(2, 20) * approximateDocumentStoreMiB,
      sizeCalculator: InMemoryLRUCache.jsonBytesSizeCalculator,
    }),
    ...moreOptions,
  })

  [PR #5644](apollographql/apollo-server#5644) [Issue #5634](apollographql/apollo-server#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](apollographql/apollo-server#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](apollographql/apollo-server#5759)
• apollo-server-fastify: Export ApolloServerFastifyConfig and FastifyContext TypeScript types. [PR #5743](apollographql/apollo-server#5743)
• apollo-server-core: Only generate the schema hash once on startup rather than twice. [PR #5757](apollographql/apollo-server#5757)
• [email protected]: 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](apollographql/apollo-server#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](apollographql/apollo-server#5270) [Issue #3577](apollographql/apollo-server#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:// github-redirect.dependabot.com/apollo-server-azure-functions: Health checks implementation apollographql/apollo-server#5003) [Issue #4925](apollographql/apollo-server#4925)
• Tests are no longer distributed inside published npm modules. [PR #5799](apollographql/apollo-server#5799) [Issue #5781](apollographql/apollo-server#5781)

v3.3.0

• 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](apollographql/apollo-server#5649) [PR #5653](apollographql/apollo-server#5653)

... (truncated)

Commits

• f3fc7d1 Release
• 06dd117 Merge pull request #5960 from apollographql/release-3.6.0
• 8b2c136 Release
• 1361265 Release
• 7eb3dff chore(deps): update dependency @​types/express-serve-static-core to v4.17.27 (...
• 2c352a9 Release
• 79554b6 chore(deps): update all non-major dependencies (#5922)
• 6203ff9 chore(deps): update dependency @​types/body-parser to v1.19.2 (#5902)
• 4009b2f Merge branch 'release-3.5.0' into main
• f1f6227 chore(deps): update dependency @​types/express-serve-static-core to v4.17.25 (...
• Additional commits viewable in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)