Update dependency apollo-server-express to v3 #33

renovate · 2021-07-12T07:33:58Z

This PR contains the following updates:

Package	Change	Age	Adoption	Passing	Confidence
apollo-server-express	`^2.14.2` -> `^3.0.0`

Release Notes

apollographql/apollo-server

`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 tpyically 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.
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`

Compare Source

apollo-server-express: Update dependencies on @types/express and @types/express-serve-static-core. PR #5352

`v2.25.1`

Compare Source

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

Compare Source

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

`v2.24.1`

Compare Source

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

`v2.24.0`

Compare Source

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

`v2.23.0`

Compare Source

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

`v2.22.2`

Compare Source

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

`v2.22.1`

Compare Source

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

`v2.22.0`

Compare Source

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

`v2.21.2`

Compare Source

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

`v2.21.1`

Compare Source

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

`v2.21.0`

Compare Source

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

`v2.20.0`

Compare Source

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

`v2.19.2`

Compare Source

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

`v2.19.1`

Compare Source

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

`v2.19.0`

Compare Source

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

`v2.18.2`

Compare Source

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

`v2.18.1`

Compare Source

apollo-server-core: Fix support for legacy option engine: {logger}, broken in v2.18.0. PR #4588
apollo-server-plugin-base: The ApolloServerPlugin TypeScript type does not need to extend AnyFunctionMap, which was an unnecessary change in v2.18.0. PR #4588
apollo-server-core: Improve a usage reporting error which occurs when you use Apollo Server in an unsupported way. PR #4588
apollo-server-core: Fix typo in error message for unparsable/invalid schemas provided via overrideReportedSchema. PR #4581

`v2.18.0`

Compare Source

apollo-server-core: When Apollo Server is configured with an Apollo API key, the URLs it uses to connect to Apollo's servers have changed. If the environment in which you run your servers requires you to explicitly allow connections by domain, you will need to add the new domain names. Usage reporting previously connected to https://engine-report.apollodata.com/ and now connects to https://usage-reporting.api.apollographql.com/; schema reporting previously connected to https://edge-server-reporting.api.apollographql.com/ and now connects to https://schema-reporting.api.apollographql.com/ . PR #4453
Apollo Server's support for communicating with Apollo’s commercial products has been refactored into three separate plugins exported from apollo-server-core (for usage reporting, schema reporting, and inline tracing), configured using the standard plugins option. The engine option continues to work for backwards compatibility in the 2.x series; support for engine will be deprecated in Apollo Server 3.x. Full details are available in the migration guide. PR #4453
To consistently support tracing, inline tracing is enabled by default on federated implementing services, even when an Apollo API key is provided. Previously it was not enabled when an API key was provided. You can disable it with ApolloServerPluginInlineTraceDisabled. PR #4453
The apollo-engine-reporting npm package has been obsoleted and will no longer receive updates. PR #4453
The apollo-engine-reporting-protobuf package has been renamed to apollo-reporting-protobuf. No new versions of the old package will be published. PR #4453
Implementations of ApolloServer for serverless frameworks such as Lambda now override the serverlessFramework() method to return true. We have changed our own integrations, but other implementations that extend ApolloServer which need this behavior should do the same. Support for engine.sendReportsImmediately will be dropped in Apollo Server 3.x. PR #4453
The GraphQLServiceContext type passed to the plugin serverWillStart method now contains apollo and serverlessFramework values. PR #4453
apollo-server-core / apollo-server-plugin-base: The request pipeline plugin API now supports a serverWillStop lifecycle hook. PR #4453
apollo-server-core: Previously, the usage reporting functionality registered one-shot handlers for the SIGINT and SIGTERM signals, which it used to send one final usage report before re-sending the signal to itself to continue shutdown. These signals handlers were installed by default if you enabled usage or schema reporting, and could be disabled by passing engine.handleSignals: false. Now, termination signal handling is the responsibility of Apollo Server as a whole rather than something specific to usage reporting. Apollo Server itself now registers these one-shot signal handlers, which trigger ApolloServer.stop(). This allows any plugin that implements the new serverWillStop callback to hook into shutdown logic, not just the usage reporting code. Similarly to before, these signal handlers are registered by default but can be disabled by via an option. We've changed the option name to stopOnTerminationSignals: false as it is more explicit about the behavior. PR #4453
apollo-server-core: The default logger implementation (if you don't specify your own logger or specify debug) now logs at the INFO level instead of the WARN level. The main effect is on a few built-in plugins which log one INFO message at startup; if a custom plugin logs at the INFO level then those messages will be visible by default as well. PR #4453
apollo-server-core: Parse and validate any schema passed via overrideReportedSchema to the schema reporting plugin, and throw accordingly on unparsable or invalid schemas.
Using Apollo Server from TypeScript now requires TypeScript 3.8 due to the use of the import type and export type directives. (If this proves to be a major problem we can revert this choice, but it makes it easier for us to ensure that certain large dependencies are only loaded when needed.) PR #4453
Updated @apollographql/graphql-playground-react to 1.7.33 to include an upstream fix. PR #4550

`v2.17.0`

Compare Source

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

`v2.16.1`

Compare Source

This release only includes patch updates to dependencies.

`v2.16.0`

Compare Source

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

`v2.15.1`

Compare Source

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

`v2.15.0`

Compare Source

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

`v2.14.5`

Compare Source

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

`v2.14.4`

Compare Source

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

`v2.14.3`

Compare Source

This release only includes patch updates to dependencies.

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.

Update dependency apollo-server-express to v3

f1b6716

TwiggyBuffalo merged commit 0714855 into master Aug 12, 2021

renovate bot deleted the renovate/major-apollo-graphql-packages branch August 12, 2021 11:46

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Update dependency apollo-server-express to v3 #33

Update dependency apollo-server-express to v3 #33

renovate bot commented Jul 12, 2021 •

edited

Loading

Update dependency apollo-server-express to v3 #33

Update dependency apollo-server-express to v3 #33

Conversation

renovate bot commented Jul 12, 2021 • edited Loading

Release Notes

BREAKING CHANGES

Bumped dependencies

Removed functionality

Modified functionality

Changes to Node.js framework integrations

Configuration

renovate bot commented Jul 12, 2021 •

edited

Loading