Lint / prettify MDX (including code blocks)

.changeset/eight-cheetahs-camp.md

@@ -0,0 +1,2 @@
+---
+---

.eslintrc.cjs

@@ -1,16 +1,21 @@
 module.exports = {
   root: true,
-  parser: '@typescript-eslint/parser',
-  plugins: ['@typescript-eslint', 'import'],
-  extends: ['plugin:import/typescript'],
+  ignorePatterns: ['**/*.js'],
   overrides: [
     {
+      extends: ['plugin:import/typescript'],
+      parser: '@typescript-eslint/parser',
+      plugins: ['@typescript-eslint', 'import'],
       // Enable import/extensions on all TS files because our ESM builds require
       // you to specify local imports as full paths with extensions. We don't
       // need this on tests because Jest doesn't require it.
       files: ['**/*.ts'],
       excludedFiles: '**/__tests__/**/*.ts',
       rules: { 'import/extensions': ['error', 'ignorePackages'] },
     },
+    {
+      extends: ['plugin:mdx/recommended', 'plugin:prettier/recommended'],
+      files: ['**/*.md?(x)'],
+    },
   ],
 };

.github/APOLLO_RELEASE_TEMPLATE.md

@@ -1,11 +1,11 @@
 Release X.Y.Z
 
-As with [release PRs in the past](https://github.com/apollographql/apollo-server/issues?q=label%3A%22%F0%9F%8F%97+release%22+is%3Aclosed), this is a PR tracking a `release-x.y.z` branch for an upcoming release of Apollo Server. 🙌   The version in the title of this PR should correspond to the appropriate branch.
+As with [release PRs in the past](https://github.com/apollographql/apollo-server/issues?q=label%3A%22%F0%9F%8F%97+release%22+is%3Aclosed), this is a PR tracking a `release-x.y.z` branch for an upcoming release of Apollo Server. 🙌 The version in the title of this PR should correspond to the appropriate branch.
 
 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, indicated 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.
+The intention of these release branches is to gather changes which are intended to land in a specific version (again, indicated 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 `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.
+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 `main`.

.prettierignore

@@ -1,13 +1,12 @@
 *.json
 *.json5
 *.yml
-*.md
-*.mdx
 *.snap
 
 dist/
 
 # Don't format generated files!
 **/generated/**
+.changeset/*
 
 .volta

.vscode/settings.json

@@ -6,5 +6,12 @@
   "files.trimTrailingWhitespace": true,
   "files.insertFinalNewline": true,
   "typescript.tsdk": "./node_modules/typescript/lib",
-  "typescript.enablePromptUseWorkspaceTsdk": true
+  "typescript.enablePromptUseWorkspaceTsdk": true,
+  "eslint.validate": [
+    "md",
+    "mdx"
+  ],
+  "eslint.options": {
+    "extensions": [".md", ".mdx"]
+  }
 }

CONTRIBUTING.md

@@ -8,12 +8,12 @@ Oh, and if you haven't already, sign up for the [Apollo community forum](https:/
 
 Here are some ways to contribute to the project, from easiest to most difficult:
 
-* [Reporting bugs](#reporting-bugs)
-* [Improving the documentation](#improving-the-documentation)
-* [Responding to issues](#responding-to-issues)
-* [Small bug fixes](#small-bug-fixes)
-* [Suggesting features](#suggesting-features)
-* [Big pull requests](#big-prs)
+- [Reporting bugs](#reporting-bugs)
+- [Improving the documentation](#improving-the-documentation)
+- [Responding to issues](#responding-to-issues)
+- [Small bug fixes](#small-bug-fixes)
+- [Suggesting features](#suggesting-features)
+- [Big pull requests](#big-prs)
 
 ## Issues
 
@@ -57,8 +57,8 @@ Once there is a consensus on the need for a new feature, proceed as listed below
 
 This includes:
 
-* Big bug fixes
-* New features
+- Big bug fixes
+- New features
 
 For significant changes to a repository, it’s important to settle on a design before starting on the implementation. This way, we can make sure that major improvements get the care and attention they deserve. Since big changes can be risky and might not always get merged, it’s good to reduce the amount of possible wasted effort by agreeing on an implementation design/plan first.
 

DEVELOPMENT.md

@@ -44,7 +44,7 @@ When at least one changeset exists, the workflow will open and update a release
 
 Apollo Server is "dual-published", shipping with both ESM and CJS, and leverages deep imports. Combined with TypeScript, this introduces a fair amount of complexity into the build infrastructure of this repository. A few quirks to keep in mind while working in this project:
 
-* Each dual-published package has 2 tsconfigs: one for ESM and one for CJS. These must also be referenced at the top-level in the respective esm/cjs-specific tsconfig files.
-* Deep imports in the `@apollo/server` package must be listed within the `package.json` ["exports"](https://nodejs.org/api/packages.html#exports) property. It's important to note that each "exports" entry must be specifically in the order: "types", "import", "require". Both [Node](https://nodejs.org/api/packages.html#exports) and [TypeScript](https://www.typescriptlang.org/docs/handbook/esm-node.html#packagejson-exports-imports-and-self-referencing)(via [`moduleResolution: "node16"`](https://www.typescriptlang.org/tsconfig#moduleResolution)) make use of these entries.
-* Additional deep imports must be represented in `server/<new-import-name>` and must contain a `package.json` file. See [`server/express4/package.json`](server/express4/package.json) for an example. This is separate from the actual source code for this new import, which should exist in `server/src/<new-import-name>`. This is used by TypeScript's CommonJS configuration (`moduleResolution: "node"`).
-* Smoke tests to ensure proper builds and importability exist in the `smoke-test` directory. If new deep imports are added, they should be incorporated into the smoke tests.
+- Each dual-published package has 2 tsconfigs: one for ESM and one for CJS. These must also be referenced at the top-level in the respective esm/cjs-specific tsconfig files.
+- Deep imports in the `@apollo/server` package must be listed within the `package.json` ["exports"](https://nodejs.org/api/packages.html#exports) property. It's important to note that each "exports" entry must be specifically in the order: "types", "import", "require". Both [Node](https://nodejs.org/api/packages.html#exports) and [TypeScript](https://www.typescriptlang.org/docs/handbook/esm-node.html#packagejson-exports-imports-and-self-referencing)(via [`moduleResolution: "node16"`](https://www.typescriptlang.org/tsconfig#moduleResolution)) make use of these entries.
+- Additional deep imports must be represented in `server/<new-import-name>` and must contain a `package.json` file. See [`server/express4/package.json`](server/express4/package.json) for an example. This is separate from the actual source code for this new import, which should exist in `server/src/<new-import-name>`. This is used by TypeScript's CommonJS configuration (`moduleResolution: "node"`).
+- Smoke tests to ensure proper builds and importability exist in the `smoke-test` directory. If new deep imports are added, they should be incorporated into the smoke tests.