Version 5

.changeset/curvy-crabs-play.md

@@ -0,0 +1,8 @@
+---
+'@apollo/server-integration-testsuite': major
+'@apollo/server-plugin-response-cache': major
+'@apollo/server-gateway-interface': major
+'@apollo/server': major
+---
+
+Drop support for Node 14 and Node 16

.changeset/five-tips-matter.md

@@ -0,0 +1,7 @@
+---
+'@apollo/server': major
+---
+
+Remove `precomputedNonce` landing page configuration option
+
+This option was introduced and subsequently deprecated in v4. Removing this configuration in v4 is strictly an improvement to the security of your landing page, and no longer exists in v5.

.changeset/orange-plants-change.md

@@ -0,0 +1,5 @@
+---
+'@apollo/server': major
+---
+
+Remove `status400ForVariableCoercionErrors` configuration option; this regression mitigation is now the default behavior in Apollo Server v5.

.circleci/config.yml

@@ -139,8 +139,6 @@ workflows:
           matrix:
             parameters:
               node-version:
-                - "14"
-                - "16"
                 - "18"
                 - "20"
       - "Check for FIXM\x45"

docs/source/api/apollo-server.mdx

@@ -485,9 +485,9 @@ If this is set to any string value, use that value instead of the environment va
 </td>
 <td>
 
-**Set this option to `true`.** It mitigates a regression introduced in Apollo Server v4 where the server returns a 200 status code (instead of 400) when a client query provides invalid variables. [Learn more.](../migration/#known-regressions)
+> Note: Apollo Server v5 defaults this option to `true`. This option is deprecated in v5 and will be ignored in a future major version.
 
-Apollo Server v5 will _always_ behave as if this option is `true` (and will ignore any provided value).
+**Apollo Server v4 users should set this option to `true`.** It mitigates a regression introduced in Apollo Server v4 where the server returns a 200 status code (instead of 400) when a client query provides invalid variables. [Learn more.](../migration/#known-regressions)
 
 </td>
 </tr>

docs/source/api/express-middleware.mdx

@@ -5,7 +5,7 @@ api_reference: true
 
 import TopLevelAwait from "../shared/top-level-await.mdx"
 
-This API reference documents Apollo Server 4's [Express](https://expressjs.com/) integration, the `expressMiddleware` function.
+This API reference documents Apollo Server's [Express](https://expressjs.com/) integration, the `expressMiddleware` function.
 
 ## `expressMiddleware`
 

docs/source/api/plugin/inline-trace.mdx

@@ -5,7 +5,7 @@ api_reference: true
 
 ## Using the plugin
 
-> 📣 **New in Apollo Server 4**: error details are not included in traces by default. For more details, see [Error Handling](../../data/errors/#masking-and-logging-errors).
+> 📣 **New since Apollo Server 4**: error details are not included in traces by default. For more details, see [Error Handling](../../data/errors/#masking-and-logging-errors).
 
 This article documents the options for the `ApolloServerPluginInlineTrace` plugin, which you can import from `@apollo/server/plugin/inlineTrace`.
 

docs/source/api/plugin/landing-pages.mdx

@@ -55,7 +55,7 @@ Available configuration options are listed in each plugin's reference below.
 
 ## Default non-production landing page
 
-In non-production environments, Apollo Server 4's landing page is an embedded version of [Apollo Sandbox](/graphos/explorer/sandbox) (served at `http://localhost:4000` by default):
+In non-production environments, Apollo Server's landing page is an embedded version of [Apollo Sandbox](/graphos/explorer/sandbox) (served at `http://localhost:4000` by default):
 
 <img class="screenshot" src="../../images/sandbox.jpeg" alt="Apollo Sandbox" />
 
@@ -636,7 +636,7 @@ If `false`, the embedded Explorer rendered by Apollo Server doesn't initialize e
 
 ## GraphQL Playground landing page
 
-By default, Apollo Server 2 provided a GraphQL Playground landing page. For migration purposes, we've published the [`@apollo/server-plugin-landing-page-graphql-playground`](https://www.npmjs.com/package/@apollo/server-plugin-landing-page-graphql-playground) package, a GraphQL Playground plugin compatible with Apollo Server 4. However, we aren't supporting this plugin with documentation or security updates since the GraphQL Playground project is officially [retired](https://github.com/graphql/graphql-playground/issues/1143) and we do not recommend its continued use. Instead, we recommend migrating to the actively maintained [Apollo Sandbox](/graphos/explorer/sandbox) (the default landing page in Apollo Server 4) at your earliest convenience.
+By default, Apollo Server 2 provided a GraphQL Playground landing page. For migration purposes, we've published the [`@apollo/server-plugin-landing-page-graphql-playground`](https://www.npmjs.com/package/@apollo/server-plugin-landing-page-graphql-playground) package, a GraphQL Playground plugin compatible with Apollo Server. However, we aren't supporting this plugin with documentation or security updates since the GraphQL Playground project is officially [retired](https://github.com/graphql/graphql-playground/issues/1143) and we do not recommend its continued use. Instead, we recommend migrating to the actively maintained [Apollo Sandbox](/graphos/explorer/sandbox) (the default landing page in Apollo Server) at your earliest convenience.
 
 ## Disabling the landing page
 

docs/source/api/plugin/usage-reporting.mdx

@@ -9,7 +9,7 @@ This plugin is designed to be used in an Apollo Gateway or in a monolithic serve
 
 ## Default installation
 
-> 📣 **New in Apollo Server 4**: error details are not included in traces by default. For more details, see [Error Handling](../../data/errors/#masking-and-logging-errors).
+> 📣 **New since Apollo Server 4**: error details are not included in traces by default. For more details, see [Error Handling](../../data/errors/#masking-and-logging-errors).
 
 Apollo Server automatically installs and enables this plugin with default settings if you [provide a graph API key and a graph ref to Apollo Server](../../monitoring/metrics/#sending-metrics-to-graphos) and your server is not a federated subgraph. You usually do this by setting the `APOLLO_KEY` and `APOLLO_GRAPH_REF` (or `APOLLO_GRAPH_ID` and `APOLLO_GRAPH_VARIANT`) environment variables. No other action is required.
 

docs/source/config.json

@@ -1,15 +1,15 @@
 {
   "title": "Apollo Server",
-  "version": "v4",
+  "version": "v4-v5",
   "algoliaFilters": [
     "docset:apollo-server",
     ["docset:apollo-client", "docset:federation"]
   ],
   "sidebar": {
     "Introduction": "/",
     "Get started": "/getting-started",
-    "New in v4": {
-      "Migrating to Apollo Server 4": "/migration",
+    "New in v4-v5": {
+      "Migrating to Apollo Server v4-v5": "/migration",
       "Previous versions": "/previous-versions",
       "Changelog": "https://github.com/apollographql/apollo-server/blob/main/packages/server/CHANGELOG.md"
     },

docs/source/data/context.mdx

@@ -9,7 +9,7 @@ You can pass useful things through your `contextValue` that any resolver might n
 
 ## The `context` function
 
-> 📣 Apollo Server 4 changes the syntax for defining a `context` function. [See more details.](../migration/#context-initialization-function)
+> 📣 Apollo Server 4 changed the syntax for defining a `context` function. [See more details.](../migration/#context-initialization-function)
 
 The `context` function should be _asynchronous_ and return an **object**. This object is then accessible to your server's resolvers and plugins using the name [`contextValue`](#the-contextvalue-object).
 

docs/source/data/errors.mdx

@@ -5,7 +5,7 @@ description: Making errors actionable on the client and server
 
 import TopLevelAwait from "../shared/top-level-await.mdx"
 
-> Apollo Server v4 introduced a regression where providing invalid variables yields a 200 status code instead of 400. To mitigate this regression, provide the `status400ForVariableCoercionErrors: true` option to your `ApolloServer` constructor. For more information, see the [migration guide](../migration/#known-regressions).
+> Apollo Server v4 introduced a regression where providing invalid variables yields a 200 status code instead of 400. To mitigate this regression, provide the `status400ForVariableCoercionErrors: true` option to your `ApolloServer` constructor. For more information, see the [migration guide](../migration/#known-regressions). This option is defaulted to true and deprecated in Apollo Server v5; it will be removed in a future major version.
 
 <!-- cSpell:ignore typenam -->
 
@@ -437,7 +437,7 @@ new ApolloServer({
 
 ### For Apollo Studio reporting
 
-> **New in Apollo Server 4:** error details are [_not_ included in traces by default](../migration#usage-reporting-and-inline-trace-plugins-mask-errors-by-default). Instead, `<masked>` replaces each error's message, and the `maskedBy` error extension replaces all other extensions. The `maskedBy` extension includes the name of the plugin that performed the masking (`ApolloServerPluginUsageReporting` or `ApolloServerPluginInlineTrace`).
+> 📣 **New since Apollo Server 4:** error details are [_not_ included in traces by default](../migration#usage-reporting-and-inline-trace-plugins-mask-errors-by-default). Instead, `<masked>` replaces each error's message, and the `maskedBy` error extension replaces all other extensions. The `maskedBy` extension includes the name of the plugin that performed the masking (`ApolloServerPluginUsageReporting` or `ApolloServerPluginInlineTrace`).
 
 You can use Apollo Studio to analyze your server's error rates. By default, the operations sent to Studio as detailed traces _don't_ contain error details.
 

docs/source/data/fetching-data.mdx

@@ -213,18 +213,18 @@ const resolvers = {
 
 Apollo Server 3 contained [an abstract class named `DataSource`](/apollo-server/v3/data/data-sources) that each of your data sources could subclass. You'd then initialize each of your `DataSource` subclasses using a special `dataSources` function, which attaches your data sources to your `context` behind the scenes.
 
-In Apollo Server 4, you can now create your data sources in the same `context` function as the rest of your per-request setup, **avoiding** the `DataSource` superclass entirely. We recommend [making a custom class for each data source](#creating-data-source-classes), with each class best suited for that particular source of data.
+Since Apollo Server 4, you can now create your data sources in the same `context` function as the rest of your per-request setup, **avoiding** the `DataSource` superclass entirely. We recommend [making a custom class for each data source](#creating-data-source-classes), with each class best suited for that particular source of data.
 
 ### Modern data sources
 
-Apollo maintains the following open-source data source for Apollo Server 4:
+Apollo maintains the following open-source data source for Apollo Server 4+:
 
 <!-- prettier-ignore -->
 | Class | Examples | For Use With |
 | --- | --- | --- |
 | [`RESTDataSource`](https://github.com/apollographql/datasource-rest) | [See Fetching Rest](./fetching-rest)|  HTTP/REST APIs |
 
-The community maintains the following open-source data sources for Apollo Server 4:
+The community maintains the following open-source data sources for Apollo Server 4+:
 
 <!-- prettier-ignore -->
 | Class | Source | For Use With |
@@ -234,7 +234,7 @@ The community maintains the following open-source data sources for Apollo Server
 
 ### Legacy data source classes
 
-> ⚠️ **Note**: The community built each data source package below for use with Apollo Server 3. [As shown below](#using-datasource-subclasses), you can still use these packages in Apollo Server 4 with a bit of extra setup.
+> ⚠️ **Note**: The community built each data source package below for use with Apollo Server 3. [As shown below](#using-datasource-subclasses), you can still use these packages in Apollo Server 4+ with a bit of extra setup.
 
 The below data source implementations extend the generic [`DataSource` abstract class](https://github.com/apollographql/apollo-server/blob/main/packages/apollo-datasource/src/index.ts), from the deprecated `apollo-datasource` package. Subclasses of `DataSource` define the logic required to communicate with a particular store or API.
 
@@ -254,7 +254,7 @@ The larger community maintains the following open-source implementations:
 
 In Apollo Server 3, immediately after constructing each `DataSource` subclass, your server would invoke the `initialize({ cache, context })` method on each new `DataSource` behind the scenes.
 
-To replicate this in Apollo Sever 4, you can manually invoke the `initialize` method in the constructor function of each `DataSource` subclass, like so:
+To replicate this in Apollo Server 4+, you can manually invoke the `initialize` method in the constructor function of each `DataSource` subclass, like so:
 
 <MultiCodeBlock>
 

docs/source/data/fetching-rest.mdx

@@ -248,7 +248,7 @@ class MoviesAPI extends RESTDataSource {
 
 ### Specifying cache TTL
 
-> 📣 **New in Apollo Server 4**: Apollo Server no longer automatically provides its cache to data sources. [See here for more details](../migration/#datasources).
+> 📣 **New since Apollo Server 4**: Apollo Server no longer automatically provides its cache to data sources. [See here for more details](../migration/#datasources).
 
 The `RESTDataSource` class can cache results from the REST API it fetches from **if either of the following is true**:
 
@@ -405,7 +405,7 @@ this.get('/movies/1', { signal: AbortSignal.timeout(myTimeoutMilliseconds) });
 
 ## Intercepting fetches
 
-> **New in Apollo Server 4**: Apollo Server 4 now uses the [`@apollo/utils.fetcher`](../migration#apolloutilsfetcher-replaces-apollo-server-env) interface under the hood for fetching. This interface lets you choose your own implementation of the Fetch API. To ensure compatibility with all Fetch implementations, the request provided to hooks like `willSendRequest` is a plain JS object rather than a `Request` object with methods.
+> **New since Apollo Server 4**: Apollo Server now uses the [`@apollo/utils.fetcher`](../migration#apolloutilsfetcher-replaces-apollo-server-env) interface under the hood for fetching. This interface lets you choose your own implementation of the Fetch API. To ensure compatibility with all Fetch implementations, the request provided to hooks like `willSendRequest` is a plain JS object rather than a `Request` object with methods.
 
 `RESTDataSource` includes a `willSendRequest` method that you can override to modify outgoing requests before they're sent. For example, you can use this method to add headers or query parameters. This method is most commonly used for authorization or other concerns that apply to all sent requests.
 

docs/source/data/subscriptions.mdx

@@ -7,7 +7,7 @@ description: Persistent GraphQL read operations
 
 **Apollo Server does not provide built-in support for subscriptions.** You can enable support for subscriptions as [described below](#enabling-subscriptions).
 
-This article uses the `graphql-ws` library to add support for subscriptions to Apollo Server 4. We no longer recommend using the previously documented `subscriptions-transport-ws`, because this library is not actively maintained. For more information about the differences between the two libraries, see [Switching from `subscriptions-transport-ws`](#switching-from-subscriptions-transport-ws).
+This article uses the `graphql-ws` library to add support for subscriptions to Apollo Server. We no longer recommend using the previously documented `subscriptions-transport-ws`, because this library is not actively maintained. For more information about the differences between the two libraries, see [Switching from `subscriptions-transport-ws`](#switching-from-subscriptions-transport-ws).
 
 </blockquote>
 
@@ -44,7 +44,7 @@ subscription PostFeed {
 
 ## Enabling subscriptions
 
-> Subscriptions are **not** supported by Apollo Server 4's `startStandaloneServer` function. To enable subscriptions, you must first [swap to using the `expressMiddleware` function](../api/express-middleware) (or any other Apollo Server integration package that supports subscriptions).
+> Subscriptions are **not** supported by Apollo Server's `startStandaloneServer` function. To enable subscriptions, you must first [swap to using the `expressMiddleware` function](../api/express-middleware) (or any other Apollo Server integration package that supports subscriptions).
 >
 > The following steps assume you've already swapped to [`expressMiddleware`](../api/express-middleware).
 
@@ -398,6 +398,7 @@ Use `withFilter` to make sure clients get exactly the subscription updates they
 
 An example server is available on [GitHub](https://github.com/apollographql/docs-examples/blob/main/apollo-server/v4/subscriptions-graphql-ws/src/index.ts) and CodeSandbox:
 
+FIXME: upgrade repo
 <a href="https://codesandbox.io/s/github/apollographql/docs-examples/tree/main/apollo-server/v4/subscriptions-graphql-ws?fontsize=14&hidenavigation=1&initialpath=%2Fgraphql&theme=dark">
   <img
     alt="Edit server-subscriptions-as4"

docs/source/getting-started.mdx

@@ -10,7 +10,7 @@ This tutorial helps you:
 - Run an instance of Apollo Server that lets you execute queries against your schema
 
 This tutorial assumes that you are familiar with the command line and
-JavaScript and have installed a recent Node.js (v14.16.0+) version. Additionally, for those interested, this tutorial includes an optional section describing how to set up Apollo Server with TypeScript.
+JavaScript and have installed a recent Node.js (v18.0.0+) version. Additionally, for those interested, this tutorial includes an optional section describing how to set up Apollo Server with TypeScript.
 
 ## Step 1: Create a new project
 
@@ -78,8 +78,8 @@ touch tsconfig.json
   "compilerOptions": {
     "rootDirs": ["src"],
     "outDir": "dist",
-    "lib": ["es2020"],
-    "target": "es2020",
+    "lib": ["es2021"],
+    "target": "es2021",
     "module": "esnext",
     "moduleResolution": "node",
     "esModuleInterop": true,
@@ -327,6 +327,7 @@ One of the most important concepts of GraphQL is that clients can choose to quer
 
 You can view and fork the complete example on Code Sandbox:
 
+FIXME: update codesandbox to v5
 <a href="https://codesandbox.io/s/github/apollographql/docs-examples/tree/main/apollo-server/v4/getting-started?fontsize=14&hidenavigation=1&theme=dark">
   <img
     alt="Edit server-getting-started"

docs/source/index.mdx

@@ -2,11 +2,11 @@
 title: Introduction to Apollo Server
 ---
 
-> 📣 **Apollo Server 4 is generally available!**
+> 📣 **Apollo Server 5 is generally available!**
 >
-> [See what's new](./migration/)! 
+> Not much has changed since v4, the [update to the migration guide](./migration/#apollo-server-5) is a one minute read.
 >
-> Docs for Apollo Server 3 are [available here](/apollo-server/v3/).
+> Using Apollo Server 3? Be sure to follow the [full migration guide](./migration/) first. Docs for v3 are [available here](/apollo-server/v3/).
 
 **Apollo Server is an [open-source](https://github.com/apollographql/apollo-server), spec-compliant GraphQL server** that's compatible with any GraphQL client, including [Apollo Client](/react). It's the best way to build a production-ready, self-documenting GraphQL API that can use data from any source.