Update docs (mostly) for v4 release on version-3

- Run docs publish workflow on version-3
- Update lots of links from main to version-3
- Don't redirect away from /v3 in docs
- renovate.json5 is ignored off of main (if we wanted to renovate this
  branch, we'd have to configure it on main using baseBranches)
- make prettier ignore _redirects (it was treating it as Markdown)

Author: glasser

.github/workflows/docs-publish.yml

@@ -5,6 +5,7 @@ on:
     branches:
       - main
       - version-2
+      - version-3
     paths:
       - docs/**
 

.prettierignore

@@ -12,3 +12,4 @@ docs/.cache/
 **/generated/**
 
 .volta
+_redirects

docs/source/_redirects

@@ -1,8 +1,3 @@
-# The v3 docs were beta for a while, and non-default, but now that they are
-# default, the v3 docs don't exist anymore.  So redirect them to the default!
-/v3 /docs/apollo-server
-/v3/* /docs/apollo-server/:splat
-
 # Updating URLs for v3
 /testing/graphql-playground/ /docs/apollo-server/testing/build-run-queries/#graphql-playground
 /deployment /docs/apollo-server/deployment/heroku
@@ -25,7 +20,7 @@
 /api/graphql-tools /docs/apollo-server/
 
 # Redirects associated with revamp of Apollo Server information architecture
-/whats-new https://github.com/apollographql/apollo-server/blob/main/CHANGELOG.md
+/whats-new https://github.com/apollographql/apollo-server/blob/version-3/CHANGELOG.md
 /essentials/data/ /docs/apollo-server/data/data/
 /essentials/schema/ /docs/apollo-server/schema/schema/
 /essentials/server /docs/apollo-server/getting-started/

docs/source/api/apollo-server.mdx

@@ -300,7 +300,7 @@ Provide this function to transform the structure of error objects before they're
 </td>
 <td>
 
-Provide this function to transform the structure of GraphQL response objects before they're sent to a client. The function takes a [`GraphQLResponse`](https://github.com/apollographql/apollo-server/blob/main/packages/apollo-server-types/src/index.ts#109-L114) object and a [`GraphQLRequestContext`](https://github.com/apollographql/apollo-server/blob/main/packages/apollo-server-types/src/index.ts#L127-L162) object, and it should return a `GraphQLResponse` object, or null to preserve the existing structure.
+Provide this function to transform the structure of GraphQL response objects before they're sent to a client. The function takes a [`GraphQLResponse`](https://github.com/apollographql/apollo-server/blob/version-3/packages/apollo-server-types/src/index.ts#109-L114) object and a [`GraphQLRequestContext`](https://github.com/apollographql/apollo-server/blob/version-3/packages/apollo-server-types/src/index.ts#L127-L162) object, and it should return a `GraphQLResponse` object, or null to preserve the existing structure.
 </td>
 </tr>
 

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

@@ -172,7 +172,7 @@ Specify this asynchronous function to configure which requests are included in u
 
  Note that returning `false` here means that the operation is completely ignored by all Apollo Studio features. If you want to improve performance by skipping the field-level execution trace, set the [`fieldLevelInstrumentation`](#fieldlevelinstrumentation) option instead of this one.
 
-This function is called for each received request. It takes a [`GraphQLRequestContext`](https://github.com/apollographql/apollo-server/blob/main/packages/apollo-server-types/src/index.ts#L115-L150) object and must return a `Promise<Boolean>` that indicates whether to include the request. It's called either after the operation is successfully resolved (via [the `didResolveOperation` event](https://www.apollographql.com/docs/apollo-server/integrations/plugins/#didresolveoperation)), or when sending the final error response if the operation was not successfully resolved (via [the `willSendResponse` event](https://www.apollographql.com/docs/apollo-server/integrations/plugins/#willsendresponse)).
+This function is called for each received request. It takes a [`GraphQLRequestContext`](https://github.com/apollographql/apollo-server/blob/version-3/packages/apollo-server-types/src/index.ts#L115-L150) object and must return a `Promise<Boolean>` that indicates whether to include the request. It's called either after the operation is successfully resolved (via [the `didResolveOperation` event](https://www.apollographql.com/docs/apollo-server/integrations/plugins/#didresolveoperation)), or when sending the final error response if the operation was not successfully resolved (via [the `willSendResponse` event](https://www.apollographql.com/docs/apollo-server/integrations/plugins/#willsendresponse)).
 
 If you don't want any usage reporting at all, don't use this option: instead, either avoid specifying an Apollo API key or explicitly [disable the plugin](#disabling-the-plugin).
 
@@ -192,7 +192,7 @@ By default, all requests are included in usage reports.
 
 Specify this function to provide Apollo Studio with client details for each processed request. Apollo Studio uses this information to [segment metrics by client](https://www.apollographql.com/docs/studio/client-awareness/).
 
-This function is passed a [`GraphQLRequestContext`](https://github.com/apollographql/apollo-server/blob/main/packages/apollo-server-types/src/index.ts#L115-L150) object containing all available information about the request. It should return an object with `clientName` and `clientVersion` fields that identify the associated client.
+This function is passed a [`GraphQLRequestContext`](https://github.com/apollographql/apollo-server/blob/version-3/packages/apollo-server-types/src/index.ts#L115-L150) object containing all available information about the request. It should return an object with `clientName` and `clientVersion` fields that identify the associated client.
 
 By default, the plugin attempts to obtain these values from the incoming request's HTTP headers (specifically, `apollographql-client-name` and `apollographql-client-version`).
 

docs/source/config.json

@@ -15,7 +15,7 @@
     "Apollo Federation": "https://www.apollographql.com/docs/federation/",
     "New in v3": {
       "Migrating to Apollo Server 3": "/migration",
-      "Changelog": "https://github.com/apollographql/apollo-server/blob/main/CHANGELOG.md"
+      "Changelog": "https://github.com/apollographql/apollo-server/blob/version-3/CHANGELOG.md"
     },
     "Defining a Schema": {
       "Schema basics": "/schema/schema",

docs/source/data/data-sources.mdx

@@ -26,15 +26,15 @@ flowchart LR;
 
 ## Open-source implementations
 
-All data source implementations extend the generic [`DataSource` abstract class](https://github.com/apollographql/apollo-server/blob/main/packages/apollo-datasource/src/index.ts), which is included in the `apollo-datasource` package. Subclasses of a `DataSource` should define whatever logic is required to communicate with a particular store or API.
+All data source implementations extend the generic [`DataSource` abstract class](https://github.com/apollographql/apollo-server/blob/version-3/packages/apollo-datasource/src/index.ts), which is included in the `apollo-datasource` package. Subclasses of a `DataSource` should define whatever logic is required to communicate with a particular store or API.
 
 Apollo and the larger community maintain the following open-source implementations:
 
-> Do you maintain a `DataSource` implementation that isn't listed here? Please [submit a PR](https://github.com/apollographql/apollo-server/blob/main/docs/source/data/data-sources.md) to be added to the list!
+> Do you maintain a `DataSource` implementation that isn't listed here? Please [submit a PR](https://github.com/apollographql/apollo-server/blob/version-3/docs/source/data/data-sources.md) to be added to the list!
 
 | Class            | Source    | For Use With          |
 |------------------|-----------|-----------------------|
-| [`RESTDataSource`](https://github.com/apollographql/apollo-server/tree/main/packages/apollo-datasource-rest) | Apollo    | REST APIs ([see below](#restdatasource-reference)) |
+| [`RESTDataSource`](https://github.com/apollographql/apollo-server/tree/version-3/packages/apollo-datasource-rest) | Apollo    | REST APIs ([see below](#restdatasource-reference)) |
 | [`HTTPDataSource`](https://github.com/StarpTech/apollo-datasource-http)  | Community | HTTP/REST APIs (newer community alternative to `RESTDataSource`) |
 | [`SQLDataSource`](https://github.com/cvburgess/SQLDataSource)  | Community | SQL databases (via [Knex.js](http://knexjs.org/)) |
 | [`MongoDataSource`](https://github.com/GraphQLGuide/apollo-datasource-mongodb/) | Community | MongoDB |
@@ -125,7 +125,7 @@ npm install apollo-datasource-rest
 You then extend the `RESTDataSource` class and implement whatever data-fetching methods your resolvers need. These methods can use built-in convenience methods (like `get` and `post`) to perform HTTP requests, helping you add query parameters, parse JSON results, and handle errors.
 
 ### API Reference
-To see the all the properties and functions that can be overridden, the [source code](https://github.com/apollographql/apollo-server/tree/main/packages/apollo-datasource-rest) is always the best option.
+To see the all the properties and functions that can be overridden, the [source code](https://github.com/apollographql/apollo-server/tree/version-3/packages/apollo-datasource-rest) is always the best option.
 
 #### Constructor Parameters
 ##### `httpFetch`
@@ -229,7 +229,7 @@ class MoviesAPI extends RESTDataSource {
 
 ### HTTP Methods
 
-`RESTDataSource` includes convenience methods for common REST API request methods: `get`, `post`, `put`, `patch`, and `delete` ([see the source](https://github.com/apollographql/apollo-server/blob/main/packages/apollo-datasource-rest/src/RESTDataSource.ts#L154-L202)).
+`RESTDataSource` includes convenience methods for common REST API request methods: `get`, `post`, `put`, `patch`, and `delete` ([see the source](https://github.com/apollographql/apollo-server/blob/version-3/packages/apollo-datasource-rest/src/RESTDataSource.ts#L154-L202)).
 
 An example of each is shown below:
 

docs/source/data/errors.mdx

@@ -42,7 +42,7 @@ Here's an example error response caused by misspelling the `__typename` field in
 
 To help with debugging, Apollo Server defines error subclasses that represent different types of errors that can occur while handling a GraphQL operation (such as `SyntaxError` and `ValidationError`). These subclasses each return a different [error code](#error-codes), which enables requesting clients to respond differently to different error types.
 
-These built-in error subclasses inherit from the generic `ApolloError` class, and they're all defined in [the `apollo-server-errors` package](https://github.com/apollographql/apollo-server/blob/main/packages/apollo-server-errors/src/index.ts). You can also [create your own custom errors and codes](#custom-errors).
+These built-in error subclasses inherit from the generic `ApolloError` class, and they're all defined in [the `apollo-server-errors` package](https://github.com/apollographql/apollo-server/blob/version-3/packages/apollo-server-errors/src/index.ts). You can also [create your own custom errors and codes](#custom-errors).
 
 ## Error codes
 

docs/source/integrations/middleware.mdx

@@ -232,7 +232,7 @@ The set of common options supported by each package is listed under [Basic usage
 
 ## Basic usage
 
-The sections below demonstrate how to initialize an `ApolloServer` instance with each package. More details are available in each package's [README](https://github.com/apollographql/apollo-server/tree/main/packages).
+The sections below demonstrate how to initialize an `ApolloServer` instance with each package. More details are available in each package's [README](https://github.com/apollographql/apollo-server/tree/version-3/packages).
 
 Each section also lists the options supported by each package's `applyMiddleware` or `getMiddleware` or `createHandler` function. Learn more about how these options work in the [`ApolloServer` API reference](../api/apollo-server/#framework-specific-middleware-function).
 

docs/source/integrations/plugins-event-reference.md

@@ -229,7 +229,7 @@ const server = new ApolloServer({
 
 ## Request lifecycle events
 
-> If you're using TypeScript to create your plugin, implement the [ `GraphQLRequestListener` interface](https://github.com/apollographql/apollo-server/blob/main/packages/apollo-server-plugin-base/src/index.ts) from the `apollo-server-plugin-base` module to define functions for request lifecycle events.
+> If you're using TypeScript to create your plugin, implement the [ `GraphQLRequestListener` interface](https://github.com/apollographql/apollo-server/blob/version-3/packages/apollo-server-plugin-base/src/index.ts) from the `apollo-server-plugin-base` module to define functions for request lifecycle events.
 
 When Apollo Server processes a request, these events fire in the order listed (with the exception of `didEncounterErrors`, which might fire in one of a few places depending on when errors occur). [See the flow diagram](./plugins/#request-lifecycle-event-flow)
 

docs/source/integrations/plugins.md

@@ -19,7 +19,7 @@ const myPlugin = {
 };
 ```
 
-> If you're using TypeScript to create a plugin, the `apollo-server-plugin-base` module exports the [`ApolloServerPlugin` interface](https://github.com/apollographql/apollo-server/blob/main/packages/apollo-server-plugin-base/src/index.ts) for plugins to implement.
+> If you're using TypeScript to create a plugin, the `apollo-server-plugin-base` module exports the [`ApolloServerPlugin` interface](https://github.com/apollographql/apollo-server/blob/version-3/packages/apollo-server-plugin-base/src/index.ts) for plugins to implement.
 
 You can define a plugin in the same file where you initialize Apollo Server, or
 you can export it as a separate module:
@@ -189,7 +189,7 @@ Note that the `validationDidStart` end hook receives an _array_ of errors that c
 
 As the example above shows, `requestDidStart` and request lifecycle functions accept a `requestContext` parameter. This parameter is of type `GraphQLRequestContext`, which includes a `request` (of type `GraphQLRequest`), along with a `response` field (of type `GraphQLResponse`) if it's available.
 
-These types and their related subtypes are all defined in [`apollo-server-types/src/index.ts`](https://github.com/apollographql/apollo-server/blob/main/packages/apollo-server-types/src/index.ts).
+These types and their related subtypes are all defined in [`apollo-server-types/src/index.ts`](https://github.com/apollographql/apollo-server/blob/version-3/packages/apollo-server-types/src/index.ts).
 
 ## Installing custom plugins
 

docs/source/migration.mdx

@@ -10,7 +10,7 @@ The focus of this major-version release is to provide a lighter, nimbler core li
 
 This document explains which features _do_ require code changes and how to make them. If you encounter issues while migrating, please [create an issue](https://github.com/apollographql/apollo-server/issues/new/choose).
 
-> For a list of all breaking changes, [see the changelog](https://github.com/apollographql/apollo-server/blob/main/CHANGELOG.md).
+> For a list of all breaking changes, [see the changelog](https://github.com/apollographql/apollo-server/blob/version-3/CHANGELOG.md).
 
 
 ## Bumped dependencies
@@ -184,7 +184,7 @@ import typeDefs from "./typeDefs";
       }
     }],
   });
-  
+
   subscriptionServer = SubscriptionServer.create({
     schema,
     execute,
@@ -197,7 +197,7 @@ import typeDefs from "./typeDefs";
     server: httpServer,
     path: server.graphqlPath,
   });
-  
+
   await server.start();
   server.applyMiddleware({ app });