chore: update dependency apollo-server-express to v3

Open renovate[bot] opened this issue 4 years ago • 2 comments

This PR contains the following updates:

Package	Change	Age	Adoption	Passing	Confidence
apollo-server-express	`^2.26.0` -> `^3.10.2`

Release Notes

apollographql/apollo-server

`v3.10.2`

Compare Source

apollo-server-fastify: Use return reply.send in handlers to match the pattern encouraged by Fastify 4 (although apollo-server-fastify@3 only works with Fastify 3). PR #6798
[email protected]: Add option memoizeGetRequests to disable GET cache PR #6650 and PR #6834

`v3.10.1`

Compare Source

⚠️ SECURITY: The default landing page contained HTML to display a sample curl command which is made visible if the full landing page bundle could not be fetched from Apollo's CDN. The server's URL is directly interpolated into this command inside the browser from window.location.href. On some older browsers such as IE11, this value is not URI-encoded. On such browsers, opening a malicious URL pointing at an Apollo Router could cause execution of attacker-controlled JavaScript. In this release, the fallback page does not display a curl command. More details are available at the security advisory.
Improve error message when both a graph ref and a graph variant are specified. PR #6709
Fix the TypeScript declaration of the fieldLevelInstrumentation option to ApolloServerPluginUsageReporting to show that the function may return a number in addition to a boolean. This now matches the implementation and docs. PR #6763

`v3.10.0`

Compare Source

Add document, variables, headers as an option in the ApolloServerPluginLandingPageLocalDefault plugins. The embedded version of Apollo Sandbox can now use these options as an initial state. PR #6628
Add generateCacheKey to ApolloServerPluginResponseCache to allow for custom cache keys. PR #6655

`v3.9.0`

Compare Source

⚠️ SECURITY apollo-server-core: The default configuration of Apollo Server is vulnerable to denial of service attacks via memory exhaustion. If you do not currently specify the cache option to new ApolloServer(), we strongly recommend you specify cache: 'bounded', which replaces the default in-memory unbounded cache with a 30MB in-memory cache, or disable automatic persisted queries with persistedQueries: false. Apollo Server now logs a warning in production if you do not configure the cache or disable APQs. See the docs for more details.
The apollo-server-caching package is no longer published. The TypeScript types KeyValueCache and KeyValueCacheSetOptions and the classes PrefixingKeyValueCache and InMemoryLRUCache can be imported from @apollo/utils.keyvaluecache instead. The first three exports are identical; InMemoryLRUCache is based on lru-cache v7 instead of v6, and no longer supports creating unbounded caches (which was the default behavior for apollo-server-caching's InMemoryLRUCache). PR #6522
The apollo-server-cache-redis and apollo-server-cache-memcached packages are no longer published (though previous versions continue to work). We recommend that users of these packages migrate to @apollo/utils.keyvadapter, which lets you connect to Redis, Memcached, or any other backend supported by the Keyv project. See the new cache backend docs for more details. PR #6541
Avoid unhandled rejection errors if the end hook from a parsingDidStart plugin method rejects. Issue #6567 PR #6559

`v3.8.2`

Compare Source

apollo-server-core: Fix usage reporting plugin "willResolveField called after stopTiming!" error caused by a race condition related to null bubbling. Issue #4472 PR #6398

`v3.8.1`

Compare Source

This is a patch release strictly for republishing over what appears to be a hiccup in NPMs service. Issue #6469

`v3.8.0`

Compare Source

Add embed as an option in the ApolloServerPluginLandingPageLocalDefault and ApolloServerPluginLandingPageProductionDefault plugins. If you pass the embed option to ApolloServerPluginLandingPageLocalDefault, the Apollo Studio Sandbox will be embedded on your Apollo Server endpoint. If you pass the embed option to ApolloServerPluginLandingPageProductionDefault, the Apollo Studio embedded Explorer will be embedded on your Apollo Server endpoint. In both cases, users can use the embedded app to run GraphQL operations without any special CORS setup.
Add a few missing dependencies to packages. PR #6393
Factor out some usage reporting code to a shared package in the apollo-utils repository. Should not be a visible change. PR #6449

`v3.7.0`

Compare Source

⚠️ SECURITY apollo-server-core: Apollo Server now includes protection against CSRF and XS-Search attacks. We highly recommend enabling this feature by passing csrfPrevention: true to new ApolloServer(). If you rely on the ability to execute GraphQL operations via HTTP GET requests using a client other than Apollo Client Web, Apollo iOS, or Apollo Kotlin (formerly Apollo Android), you may need to first change the configuration of that client. See the CSRF prevention docs for more details. This vulnerability was reported by Jeffrey Hofmann; the feature was designed with advice from Luca Carettoni of Doyensec.

`v3.6.8`

Compare Source

apollo-server-fastify: This package now depends on the @fastify/accepts and @fastify/cors packages rather than their older deprecated names fastify-accepts and fastify-cors. There is no behavior change (except that you will no longer see deprecation messages). PR #6366
apollo-server-types: The Logger TypeScript interface is now re-exported from the new @apollo/utils.logger package instead of defined directly in this package; other packages import it from the new package. There should be no observable change. PR #6229

`v3.6.7`

Compare Source

apollo-server-core: Update @apollographql/apollo-tools dependency to the latest version which now properly lists its peer dependencies. This fixes a problem with using Yarn3 PnP PR #6273

`v3.6.6`

Compare Source

⚠️ SECURITY apollo-server-core: Apollo Server 3.4.0 introduced a new documentStore constructor option (replacing the experimental_approximateDocumentStoreMiB option) which allows you to customize an internal cache used by ApolloServer to memoize the results of parsing and validating GraphQL operations. When this option was combined with the gateway option, it was possible for Apollo Server to attempt to execute invalid GraphQL operations. Specifically, if a server processed an operation and then its schema was updated with a change that made that operation no longer valid, the server could still attempt to execute the operation again without re-validating it against the new schema. The problem only lasts until the server is restarted. This release changes the semantics of the documentStore option so that a different key prefix is used each time the schema is updated. (As a side effect, you no longer have to be careful to avoid sharing a documentStore between multiple ApolloServer objects.) This update is highly recommended for any users that specify both documentStore and gateway in new ApolloServer().

`v3.6.5`

Compare Source

apollo-server-plugin-usage-reporting: Stop distributing unnecessary generated/reports.proto file. Count executable operations. PR #6239

`v3.6.4`

Compare Source

apollo-server-core: Fixes a regression in v3.6.0 where usage reporting would never send traces for unexecutable operations (parse errors, validation errors, and unknown operation name errors). While "traces" for these operations won't actually contain an execution tree, they can contain interesting errors. Issue #6193 PR #6194

`v3.6.3`

Compare Source

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

`v3.6.2`

Compare Source

⚠️ 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, 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 [email protected] 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
apollo-server-fastify: Drop dependency on fast-json-stringify. PR #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; 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

`v3.6.1`

Compare Source

Correctly remove dependency on apollo-graphql as intended in v3.6.0. Issue #5981 PR #5981

`v3.6.0`

Compare Source

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 PR #5956 PR #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
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 PR #5955

`v3.5.0`

Compare Source

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

`v3.4.1`

Compare Source

⚠️ 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`

Compare Source

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.sizeCalculator,
  }),
  ...moreOptions,
})
```
PR #5644 Issue #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
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
apollo-server-fastify: Export ApolloServerFastifyConfig and FastifyContext TypeScript types. PR #5743
apollo-server-core: Only generate the schema hash once on startup rather than twice. PR #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
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 Issue #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.com/apollographql/apollo-server/pull/50033) Issue #4925
Tests are no longer distributed inside published npm modules. PR #5799 Issue #5781

`v3.3.0`

Compare Source

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 PR #5653

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 or the basic usage for your integration of choice.

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
apollo-server-core: Fix experimental_approximateDocumentStoreMiB option, which seems to have never worked before. PR #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

`v3.1.2`

Compare Source

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`

Compare Source

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 gets correct. PR #5537

`v3.1.0`

Compare Source

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 Issue #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. PR #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
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
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

`v3.0.2`

Compare Source

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

`v3.0.1`

Compare Source

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
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
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 Issue #5462

`v3.0.0`

Compare Source

BREAKING CHANGES

Apollo Server 3 contains quite a few breaking changes. Read our migration guide 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 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.
- For example, mock functions no longer receive arguments and cannot return Promises.
- 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.
- 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.
Dropped support for the graphql-extensions API (e.g., GraphQLExtensions, extensions) in favor of the Apollo Server plugins API.
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, and you might want to consider the newer schemaTransforms 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.
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.
- 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. 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. For more details, see PR #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 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.

Configuration

📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - 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, click this checkbox.

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

Aug 03 '21 06:08 renovate[bot]

Pull Request Test Coverage Report for Build 3104768293

8 of 8 (100.0%) changed or added relevant lines in 3 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 55.114%

Totals
Change from base Build 3104680662:	0%
Covered Lines:	9546
Relevant Lines:	12415

💛 - Coveralls

Sep 01 '22 14:09 coveralls

@loopbackio/loopback-maintainers mark this update as breaking change?

Sep 02 '22 07:09 frbuceta