fix(deps): update apollo graphql packages (major) #3809
Closed
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR contains the following updates:
^0.14.0
->^3.0.0
^2.18.2
->^3.0.0
Release Notes
apollographql/apollo-server
v3.4.0
Compare Source
apollo-server-core
: You can now specify your ownDocumentStore
(aKeyValueStore<DocumentNode>
) for Apollo Server's cache of parsed and validated GraphQL operation abstract syntax trees via the newdocumentStore
constructor option. This replaces theexperimental_approximateDocumentStoreMiB
option. You can replacenew ApolloServer({experimental_approximateDocumentStoreMiB: approximateDocumentStoreMiB, ...moreOptions})
with:apollo-server-core
: For ease of testing, you can specify the node environment vianew ApolloServer({nodeEnv})
in addition to via theNODE_ENV
environment variable. The environment variable is now only read during server startup (and in some error cases) rather than on every request. PR #5657apollo-server-koa
: The peer dependency onkoa
(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 ofkoa
are released. PR #5759apollo-server-fastify
: ExportApolloServerFastifyConfig
andFastifyContext
TypeScript types. PR #5743apollo-server-core
: Only generate the schema hash once on startup rather than twice. PR #5757apollo-datasource-rest@3.3.0
: When choosing whether or not to parse a response as JSON, treat anycontent-type
ending in+json
as JSON rather than justapplication/hal+json
(in addition toapplication/json
). PR #5737apollo-server
: You can now configure the health check URL path with thehealthCheckPath
constructor option, or disable serving health checks by passingnull
for this option. (This option is specific to the batteries-includedapollo-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 #3577apollo-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 withdisableHealthCheck
andonHealthCheck
. [PR #5003](https://github.com/apollographql/apollo-server/pull/50033) Issue #4925v3.3.0
Compare Source
apollo-server-core
: Error handling when aserverWillStop
callback invoked byserver.stop()
(orgateway.stop()
) throws is now consistent: the original call toserver.stop()
throws the error, and any concurrent and subsequent calls toserver.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 thedrainServer
hook introduced in Apollo Server v3.2.0 are now handled in the same way. Issue #5649 PR #5653v3.2.0
Compare Source
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 forApolloServerPluginDrainHttpServer
or the basic usage for your integration of choice.apollo-server-core
: Previously, only the batteries-includedapollo-server
package supported a graceful shutdown. Now the integrations support it as well, if you tell yourApolloServer
which HTTP server to drain with the newApolloServerPluginDrainHttpServer
plugin. This plugin implements a newdrainServer
plugin hook. Forapollo-server-hapi
you can useApolloServerPluginStopHapiServer
instead. PR #5635apollo-server-core
: Fixexperimental_approximateDocumentStoreMiB
option, which seems to have never worked before. PR #5629apollo-server-core
: Only registerSIGINT
andSIGTERM
handlers once the server successfully starts up; trying to callstop
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 explicitstart
call); you can still explicitly setstopOnTerminationSignals
to override this default. PR #5639v3.1.1
Compare Source
apollo-server-env
: UpdateHeaders.values()
type to match whatnode-fetch
actually does and what the Fetch spec says it should be, and what@types/node-fetch
finally gets correct. PR #5537v3.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 anextensions.code
ofBAD_USER_INPUT
rather thanINTERNAL_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 #5353apollo-server-core
/apollo-server-plugin-base
: Add support forschemaDidLoadOrUpdate
event hooks, to be specified by theserverWillStart
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 #5187apollo-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 least0.35.0
, or elsestart()
will error. PR #5187apollo-server-core
: Support gateways without executors, to help with mocking gateways. Note that if you have a customGatewayInterface
implementation, Apollo Server will now honor theexecutor
returned fromload
and will ignore theexecutor
method on the gateway itself. See the PR for details. PR #5539apollo-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 #5542v3.0.2
Compare Source
apollo-server-types
: TypeScript typings forinfo.cacheControl
are now added toGraphQLResolveInfo
as part ofapollo-server-types
rather than a nested file inapollo-server-core
, and the field now has a named type,ResolveInfoCacheControl
. PR #5512apollo-server-micro
: Like the other framework integrations, only serve landing pages from the GraphQL path (/graphql
by default, configurable via thepath
option tocreateHandler
). PR #5516apollo-server-env
: Remove polyfills ofObject.values
,Object.entries
, andutil.promisify
which were only required for Node 6 support. RemoveValueOrPromise
andWithRequired
TypeScript types that are also provided byapollo-server-types
. PR #5515v3.0.1
Compare Source
apollo-server-core
: The defaultmaxAge
(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) functioninfo.cacheControl.cacheHint.restrict({ maxAge: 60 })
, it should setmaxAge
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 checkinginfo.cacheControl.cacheHint
now only shows explicitly-setmaxAge
and not the default, but this seems like it will be helpful since it lets you differentiate between the two similar circumstances.) PR #5492apollo-server-lambda
: Fix TypeScript types forcontext
function. (In 3.0.0, the TS types for thecontext
function were accidentally inherited fromapollo-server-express
instead of using the correct Lambda-specific types). PR #5481apollo-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 ofapollo-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 #5462v3.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.
graphql
library prior to15.3.0
.mocks
option of theApolloServer
constructor now uses@graphql-tools/mock
v7 instead ofgraphql-tools
v4, which causes some breaking changes.Promise
s.resolvers
argument toaddMocksToSchema
. Apollo Server does not support this option, but you can calladdMocksToSchema
yourself and pass the result to theschema
option of theApolloServer
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.subscriptions-transport-ws
has not been actively maintained.Dropped built-in support for file uploads via the
graphql-upload
package.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 theApolloServer
constructor.This option was passed directly to the
graphql-tools
functionmakeExecutableSchema
. To continue using it, you can importmakeExecutableSchema
from@graphql-tools/schema
and call it yourself:Note that
graphql-tools
calls this feature "legacy" schema directives, and you might want to consider the newerschemaTransforms
option instead.Removed the deprecated
ApolloServer.schema
field, which never worked with federated gateways.serverWillStart
or registeronSchemaChange
on your gateway.apollo-datasource-rest
: We no longer officially support overriding thebaseURL
property with a getter, because TypeScript 4 does not allow you to do so.Removed the automatic addition of the
@cacheControl
directive to schemas.@cacheControl
, you can define it in your schema as shown in the docs.Removed the
tracing
option passed to theApolloServer
constructor. The correspondingapollo-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 deprecatedengineproxy
and GraphQL Playground.If you rely on this trace format, the old version of
apollo-tracing
should still work:Removed a redundant mechanism for applying extensions to an
ApolloError
.error.extensions
, and are not also available onerror
itself.ForbiddenError
andAuthenticationError
constructors now allow you to pass additional extensions.Removed the
cacheControl
option passed to theApolloServer
constructor.Cache-Control
HTTP header. However, this is now implemented directly insideapollo-server-core
instead of inside a separateapollo-cache-control
package (this package has been deprecated and is no longer being published).defaultMaxAge
is now done via the newly exportedApolloServerPluginCacheControl
plugin, instead of as a top-level constructor option. This follows the same pattern as other built-in plugins like usage reporting.CacheHint
andCacheScope
types are now exported fromapollo-server-types
. Theinfo.cacheControl.cacheHint
object now has additional methods (replace
,restrict
, andpolicyIfCacheable
), and its fields update when those methods orsetCacheHint
are called. These methods also exist onrequestContext.overallCachePolicy
, which is always defined and which should not be overwritten (usereplace
instead). There is also a new functioninfo.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 defaultmaxAge
is applied to them).@cacheControl(inheritMaxAge: true)
when applied to a composite type or a field returning a composite type means that the defaultmaxAge
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 fromapollo-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'slib.dom.d.ts
— e.g., itsRequestInfo
type definition. For more details, see PR #5165.Top-level exports have changed. For example:
graphql-tools
(includingmakeExecutableSchema
) from all Apollo Server packages. To continue using them, installgraphql-tools
or one of its sub-packages yourself.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 aroundserver.executeOperation
, which you can use directly.apollo-server-caching
: The test suite helper works differently, and theTestableKeyValueCache
interface is removed.The
engine
constructor option,ENGINE_API_KEY
environment variable, andENGINE_SCHEMA_TAG
environment variables are no longer supported. Use theapollo
constructor option,APOLLO_KEY
environment variable, andAPOLLO_GRAPH_VARIANT
environment variable instead, as described in [theengine
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 ornew ApolloServer({apollo: {key}})
, Apollo Server 3 no longer parses the key to guess your Studio graph ID. You must specify it yourself, either via theAPOLLO_GRAPH_ID
environment variable (ornew ApolloServer({apollo: {graphId}})
), or as a graph ref along with the variant (e.g.,your-graph-id@your-graph-variant
) in theAPOLLO_GRAPH_REF
environment variable (ornew ApolloServer({apollo: {graphRef}})
).Modified functionality
requestDidStart
,didResolveOperation
, etc.) are nowasync
.async
, and some were "sometimes-async
" by returning aValueOrPromise
.willResolveField
, which remains synchronous. This method is called much more often than any other plugin method, and converting it toasync
might affect performance.willResolveField
might become "sometimes-async
" by returning aValueOrPromise
.willSendResponse
plugin lifecycle event after firingdidEncounterError
.willSendResponse
.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 calledexecutionDidEnd
on an object.GraphQLService
interface toGatewayInterface
.renderLandingPage
hook that returns an HTML page to serve to browsers.ApolloServerPluginLandingPageProductionDefault
andApolloServerPluginLandingPageLocalDefault
) are installed by default (the former whenNODE_ENV
isproduction
, the latter otherwise) with instructions on how to communicate with the server, links to Apollo Sandbox, etc.ApolloServerPluginLandingPageGraphQLPlayground
plugin can be installed instead to continue to use GraphQL Playground instead. Theplayground
option provided to theApolloServer
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 towindow.location.href
(with most query parameters removed). This means you typically don't have to manually configure the endpoint when using GraphQL Playground.ApolloServerPluginLandingPageDisabled
plugin.defaultPlaygroundOptions
,PlaygroundConfig
, orPlaygroundRenderPageOptions
.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.apollo-server
library or to serverless framework integrations.apollo-server-express
no longer officially supports using with theconnect
framework.connect
compatibility code, and we do still test that it works withconnect
. 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 aroundapollo-server-express
.createHandler
's argument now has different options:expressGetMiddlewareOptions
, which includes options likecors
and is passed through toapollo-server-express
'sgetMiddleware
expressAppFromMiddleware
, which lets you customize HTTP processingAlso, the
context
function now receives anexpress: { req, res }
option in addition toevent
andcontext
apollo-server-lambda
: The handler returned bycreateHandler
can now only be called as an async function returning aPromise
(it no longer optionally accepts a callback as the third argument).exports.handler = server.createHandler()
will keep working without any changes).createHandler
with a callback, you'll need to handle itsPromise
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 forapollo-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: "before 3am on Monday" (UTC).
🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.
♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
👻 Immortal: This PR will be recreated if closed unmerged. Get config help if that's undesired.
This PR has been generated by WhiteSource Renovate. View repository job log here.