⚠️ Update the default branch of the Apollo Server repository.

.github/APOLLO_RELEASE_TEMPLATE.md

@@ -4,8 +4,8 @@ As with [release PRs in the past](https://github.com/apollographql/apollo-server
 
 Check the appropriate milestone (to the right) for more details on what we hope to get into this release!
 
-The intention of these release branches is to gather changes which are intended to land in a specific version (again, indiciated by the subject of this PR).  Release branches allow additional clarity into what is being staged, provide a forum for comments from the community pertaining to the release's stability, and to facilitate the creation of pre-releases (e.g. `alpha`, `beta`, `rc`) without affecting the `master` branch.
+The intention of these release branches is to gather changes which are intended to land in a specific version (again, indiciated by the subject of this PR).  Release branches allow additional clarity into what is being staged, provide a forum for comments from the community pertaining to the release's stability, and to facilitate the creation of pre-releases (e.g. `alpha`, `beta`, `rc`) without affecting the `main` branch.
 
-PRs for new features might be opened against or re-targeted to this branch by the project maintainers.  The `master` branch may be periodically merged into this branch up until the point in time that this branch is being prepared for release.  Depending on the size of the release, this may be once it reaches RC (release candidate) stage with an `-rc.x` release suffix.  Some less substantial releases may be short-lived and may never have pre-release versions.
+PRs for new features might be opened against or re-targeted to this branch by the project maintainers.  The `main` branch may be periodically merged into this branch up until the point in time that this branch is being prepared for release.  Depending on the size of the release, this may be once it reaches RC (release candidate) stage with an `-rc.x` release suffix.  Some less substantial releases may be short-lived and may never have pre-release versions.
 
-When this version is officially released onto the `latest` npm tag, this PR will be merged into `master`.
+When this version is officially released onto the `latest` npm tag, this PR will be merged into `main`.

.github/ISSUE_TEMPLATE.md

@@ -4,17 +4,17 @@
           or discuss it on our Spectrum.chat community (https://spectrum.chat/apollo).
 * 💡 Feature requests?
           Please search for an existing feature request before opening a new one.
-          If there is an existing feature request, use the 👍 to show your support 
-          for it.  If the specifics of your use case are not covered in the existing 
-          conversation, please take the time to *add new conversation* which helps 
+          If there is an existing feature request, use the 👍 to show your support
+          for it.  If the specifics of your use case are not covered in the existing
+          conversation, please take the time to *add new conversation* which helps
           move the feature's design forward.
 * ❗️ Bug?
           This is the right place! 😄
 
 Before reporting a bug, please check for existing or closed issues
 first and read the instructions for filing a bug report:
 
-https://github.com/apollographql/apollo-server/blob/master/CONTRIBUTING.md#reporting-bugs
+https://github.com/apollographql/apollo-server/blob/main/CONTRIBUTING.md#reporting-bugs
 
 ### This bug report should include:
 

.github/PULL_REQUEST_TEMPLATE.md

@@ -24,7 +24,7 @@ Here are some important details to follow:
           please _try_ to add a test which verifies the fix.  If you cannot, you should
           still submit the PR but we may still ask you (and help you!) to create a test.
 * 📖 Contribution guidelines
-          Follow https://github.com/apollographql/apollo-server/blob/master/CONTRIBUTING.md
+          Follow https://github.com/apollographql/apollo-server/blob/main/CONTRIBUTING.md
           when submitting a pull request.  Make sure existing tests still pass, and add
           tests for all new behavior.
 * ✏️ Explain your pull request

CHANGELOG.md

@@ -2,14 +2,14 @@
 
 The version headers in this history reflect the versions of Apollo Server itself.  Versions of other packages (e.g. which are not actual HTTP integrations; packages not prefixed with `apollo-server`) may use different versions.  For more details, check the publish commit for that version in the Git history, or check the individual CHANGELOGs for specific packages which are maintained separately:
 
-- [__CHANGELOG for `@apollo/gateway`__](https://github.com/apollographql/apollo-server/blob/master/packages/apollo-gateway/CHANGELOG.md)
-- [__CHANGELOG for `@apollo/federation`__](https://github.com/apollographql/apollo-server/blob/master/packages/apollo-federation/CHANGELOG.md)
+- [__CHANGELOG for `@apollo/gateway`__](https://github.com/apollographql/apollo-server/blob/main/packages/apollo-gateway/CHANGELOG.md)
+- [__CHANGELOG for `@apollo/federation`__](https://github.com/apollographql/apollo-server/blob/main/packages/apollo-federation/CHANGELOG.md)
 
 ### vNEXT
 
 > The changes noted within this `vNEXT` section have not been released yet.  New PRs and commits which introduce changes should include an entry in this `vNEXT` section as part of their development.  With few exceptions, the format of the entry should follow convention (i.e., prefix with package name, use markdown `backtick formatting` for package names and code, suffix with a link to the change-set à la `[PR #YYY](https://link/pull/YYY)`, etc.).  When a release is being prepared, a new header will be (manually) created below and the appropriate changes within that release will be moved into the new section.
 
-- _Nothing yet! Stay tuned!_
+- 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](https://github.com/apollographql/apollo-server/pull/4302)
 
 ### v2.15.0
 

DEVELOPMENT.md

@@ -8,8 +8,8 @@ For now, this will be a collection of tips and tricks for the maintainers of the
 
 Depending on the size of the release, it may be ideal to have a staging PR which gathers the various features we're intending on releasing into the version.  This can be a great way for the community to understand the scope of a release and a clear way for maintainers to publicize it and gather feedback.
 
-1. Create a branch off `master` named `release-X.Y.Z`, where `X.Y.Z` is the intended release.
-2. Edit the `CHANGELOG.md`, removing the `vNEXT` section entirely.  This section will remain on `master` and be resolved during the merge.
+1. Create a branch off `main` named `release-X.Y.Z`, where `X.Y.Z` is the intended release.
+2. Edit the `CHANGELOG.md`, removing the `vNEXT` section entirely.  This section will remain on `main` and be resolved during the merge.
 3. Add a new section for `### vX.Y.Z` with a bullet indicating that something is coming soon:
 
    ```
@@ -18,9 +18,9 @@ Depending on the size of the release, it may be ideal to have a staging PR which
    - Nothing yet! Stay tuned.
    ```
 
-4. Commit this change so GitHub will allow a PR to be opened against `master` with a notable change.  A suggested commit message is `Prepare CHANGELOG.md for upcoming vX.Y.Z release.`
+4. Commit this change so GitHub will allow a PR to be opened against `main` with a notable change.  A suggested commit message is `Prepare CHANGELOG.md for upcoming vX.Y.Z release.`
 5. Push the branch to GitHub
-6. On GitHub, open a PR from the new release branch which targets `master`.
+6. On GitHub, open a PR from the new release branch which targets `main`.
    __For the title of the PR__, use "Release X.Y.Z".  __For the body,__ use the contents of the template in the `.github/APOLLO_RELEASE_TEMPLATE.md` file in this repository.  Adjust the body as you see necessary.
 
 ## Publishing a release
@@ -35,7 +35,7 @@ To bump the version, use the `release:version-bump` npm script.
 
    __Option 1__: _(Recommended)_ Bump all packages by the same version bump (e.g. patch, minor, prerelease, etc.).
 
-   > __Note__: Be sure to replace `<version-bump>` in the following command with the appropriate [version bump keyword](https://github.com/lerna/lerna/tree/master/commands/version#semver-bump).
+   > __Note__: Be sure to replace `<version-bump>` in the following command with the appropriate [version bump keyword](https://github.com/lerna/lerna/tree/f6e7a13e60/commands/version#semver-bump)
 
    ```
    npm run release:version-bump -- <version-bump>
@@ -67,7 +67,7 @@ __In the event that publishing via CI/CD is not possible, it may be done manuall
 1. Log into `npm` with the `apollo-bot` user.
 
 The `apollo-bot` user credentials are available to project owners, but generally used by CI/CD.
-Logging in with the follwing command will use a different npm user configuration file at `$HOME/.npmrc-apollo-bot` so as not to override personal login credentials which may already be used.
+Logging in with the following command will use a different npm user configuration file at `$HOME/.npmrc-apollo-bot` so as not to override personal login credentials which may already be used.
 
 ```
 NPM_CONFIG_USERCONFIG="$HOME/.npmrc-apollo-bot" npm login

docs/gatsby-config.js

@@ -19,7 +19,7 @@ module.exports = {
           null: [
             'index',
             'getting-started',
-            '[Changelog](https://github.com/apollographql/apollo-server/blob/master/CHANGELOG.md)',
+            '[Changelog](https://github.com/apollographql/apollo-server/blob/main/CHANGELOG.md)',
           ],
           'Defining a Schema': [
             'schema/schema',

docs/source/api/apollo-gateway.mdx

@@ -61,7 +61,7 @@ example of using `ApolloGateway`, see [The gateway](/federation/gateway/).
 
     If you provide this function, `ApolloGateway` calls it for every
     implementing service in your data graph. The function must return an object
-    that implements the [`GraphQLDataSource` interface](https://github.com/apollographql/apollo-server/blob/master/packages/apollo-gateway/src/datasources/types.ts), such as an instance of [RemoteGraphQLDataSource](#remotegraphqldatasource) or a subclass of it.
+    that implements the [`GraphQLDataSource` interface](https://github.com/apollographql/apollo-server/blob/570f548b88/packages/apollo-gateway/src/datasources/types.ts), such as an instance of [RemoteGraphQLDataSource](#remotegraphqldatasource) or a subclass of it.
 
     The example below demonstrates adding an `x-user-id`
     HTTP header to every request the gateway sends to an implementing service:

docs/source/data/resolvers.mdx

@@ -358,7 +358,7 @@ Resolver functions take the following positional arguments, in order:
 | `parent` | <p>The return value of the resolver for this field's parent (i.e., the previous resolver in the [resolver chain](#resolver-chains)).</p><p>For resolvers of top-level fields with no parent (such as fields of `Query`), this value is obtained from the `rootValue` function passed to [Apollo Server's constructor](/api/apollo-server/#apolloserver).</p>  |
 | `args` |  <p>An object that contains all GraphQL arguments provided for this field.</p><p> For example, when executing `query{ user(id: "4") }`, the `args` object passed to the `user` resolver is `{ "id": "4" }`.</p> |
 | `context` | <p>An object shared across all resolvers that are executing for a particular operation. Use this to share per-operation state, including authentication information, dataloader instances, and anything else to track across resolvers. </p><p>See [The `context` argument](#the-context-argument) for more information.</p> |
-| `info` | <p>Contains information about the operation's execution state, including the field name, the path to the field from the root, and more. </p><p>Its core fields are listed in the [GraphQL.js source code](https://github.com/graphql/graphql-js/blob/master/src/type/definition.js#L917-L928), and it is extended with additional functionality by other modules, like [`apollo-cache-control`](https://github.com/apollographql/apollo-server/tree/master/packages/apollo-cache-control).</p> |
+| `info` | <p>Contains information about the operation's execution state, including the field name, the path to the field from the root, and more. </p><p>Its core fields are listed in the [GraphQL.js source code](https://github.com/graphql/graphql-js/blob/master/src/type/definition.js#L917-L928), and it is extended with additional functionality by other modules, like [`apollo-cache-control`](https://github.com/apollographql/apollo-server/tree/570f548b887/packages/apollo-cache-control).</p> |
 
 ### The `context` argument
 

docs/source/data/subscriptions.md

@@ -247,6 +247,6 @@ The Apollo Server implementation of `PubSub` can be replaced by another implemen
 - [Kafka](https://github.com/ancashoria/graphql-kafka-subscriptions)
 - [Postgres](https://github.com/GraphQLCollege/graphql-postgres-subscriptions)
 - [Google Cloud Firestore](https://github.com/MrBoolean/graphql-firestore-subscriptions)
-- [Add your implementation...](https://github.com/apollographql/apollo-server/pull/new/master)
+- [Add your implementation...](https://github.com/apollographql/apollo-server/pull/new/main)
 
 You can implement a `PubSub` of your own, using the exported `PubSubEngine` interface from `apollo-server` or another integration. If you want to set up a GraphQL server using the `graphql-subscriptions` package (not recommended for production), follow [this guide](https://www.apollographql.com/docs/graphql-subscriptions/).

docs/source/deployment/heroku.md

@@ -51,7 +51,7 @@ $ heroku git:remote -a <HEROKU_APP_NAME>
 
 $ git add .
 $ git commit -am "make it better"
-$ git push heroku master # or your branch name
+$ git push heroku # Specify your branch name, if necessary.
 ```
 
 Send a query to your GraphQL service at your Heroku Application at `<HEROKU_APP_NAME>.herokuapp.com`

docs/source/deployment/netlify.md

@@ -127,7 +127,7 @@ Now, commit and push:
 ```bash
 git add .
 git commit -m "Add Apollo Server and Client"
-git push -u origin master
+git push -u origin # Specify your branch name, if necessary.
 ```
 
 Check the repository to make sure the code showed up.

docs/source/federation/metrics.md

@@ -26,7 +26,7 @@ These options will cause the Apollo gateway to collect tracing information from
 
 > NOTE: this section details how the gateway communicates with federated services around encoded tracing information and is not necessary to understand in order to enable federated tracing.
 
-The Apollo gateway looks to the `extensions` field of all service responses for the presence of an `ftv1` field. This field contains a representation of the tracing information for the sub-query that was executed against the service, sent as the Base64 encoding of the [protobuf representation](https://github.com/apollographql/apollo-server/blob/master/packages/apollo-engine-reporting-protobuf/src/reports.proto) of the trace. In order to request this information of federated services, the gateway will send the header pair `'apollo-federation-include-trace': 'ftv1'` on fetches if configured to collect metrics, as per above. By default a federated Apollo Server service will recognize this header pair and attach tracing information in extensions of the response.
+The Apollo gateway looks to the `extensions` field of all service responses for the presence of an `ftv1` field. This field contains a representation of the tracing information for the sub-query that was executed against the service, sent as the Base64 encoding of the [protobuf representation](https://github.com/apollographql/apollo-server/blob/main/packages/apollo-engine-reporting-protobuf/src/reports.proto) of the trace. In order to request this information of federated services, the gateway will send the header pair `'apollo-federation-include-trace': 'ftv1'` on fetches if configured to collect metrics, as per above. By default a federated Apollo Server service will recognize this header pair and attach tracing information in extensions of the response.
 
 ## How traces are constructed and aggregated
 

docs/source/federation/other-servers.md

@@ -19,4 +19,4 @@ The following is a list of known open source GraphQL server libraries that have
 | Ruby        | graphql-ruby  | [apollo-federation-ruby](https://github.com/Gusto/apollo-federation-ruby)        |
 | Rust        | async-graphql | [async-graphql](https://github.com/async-graphql/async-graphql)                  |
 
-Do you maintain a library that implements Apollo Federation that isn't listed here? Please [submit a PR](https://github.com/apollographql/apollo-server/tree/master/docs/source/federation/other-servers.md) to be added to the list!
+Do you maintain a library that implements Apollo Federation that isn't listed here? Please [submit a PR](https://github.com/apollographql/apollo-server/tree/main/docs/source/federation/other-servers.md) to be added to the list!

docs/source/integrations/plugins.md

@@ -25,7 +25,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/master/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/main/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:
@@ -194,7 +194,7 @@ As the example above shows, `requestDidStart` and request lifecycle functions ac
 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/master/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/main/packages/apollo-server-types/src/index.ts).
 
 ## Installing a plugin
 
@@ -312,7 +312,7 @@ should not return a value.
 
 ### Request lifecycle events
 
-> If you're using TypeScript to create your plugin, implement the [ `GraphQLRequestListener` interface](https://github.com/apollographql/apollo-server/blob/master/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/main/packages/apollo-server-plugin-base/src/index.ts) from the `apollo-server-plugin-base` module to define functions for request lifecycle events.
 
 ### `didResolveSource`
 

docs/source/monitoring/metrics.md

@@ -26,7 +26,7 @@ APOLLO_KEY=YOUR_API_KEY APOLLO_GRAPH_VARIANT=development node start-server.js
 
 ### Debugging Apollo Studio reporting
 
-You can set the [`debugPrintReports` option](https://github.com/apollographql/apollo-server/blob/master/packages/apollo-engine-reporting/src/agent.ts#L429-L433) in the `engine` section of the `ApolloServer` constructor to automatically log debugging information for all reporting requests sent to Apollo Studio.  For example:
+You can set the [`debugPrintReports` option](https://github.com/apollographql/apollo-server/blob/main/packages/apollo-engine-reporting/src/agent.ts#L429-L433) in the `engine` section of the `ApolloServer` constructor to automatically log debugging information for all reporting requests sent to Apollo Studio.  For example:
 
 ```js{8}
 const { ApolloServer } = require("apollo-server");
@@ -98,7 +98,7 @@ server.listen().then(({ url }) => {
 });
 ```
 
-Specifying this function overrides the [`defaultGenerateClientInfo` function](https://github.com/apollographql/apollo-server/blob/master/packages/apollo-engine-reporting/src/extension.ts#L205-L228) that Apollo Server calls otherwise.
+Specifying this function overrides the [`defaultGenerateClientInfo` function](https://github.com/apollographql/apollo-server/blob/main/packages/apollo-engine-reporting/src/extension.ts#L205-L228) that Apollo Server calls otherwise.
 
 ## Logging