typescript-eslint · JoshuaKGoldberg · Jul 31, 2024 · Apr 15, 2024 · Apr 15, 2024 · Apr 19, 2024
diff --git a/.cspell.json b/.cspell.json
@@ -49,6 +49,8 @@
   "words": [
     "Airbnb",
     "Airbnb's",
+    "ambiently",
+    "allowdefaultproject",
     "allowdefaultprojectforfiles",
     "ambiently",
     "Arka",
@@ -98,6 +100,7 @@
     "esquery",
     "esrecurse",
     "estree",
+    "extrafileextensions",
     "falsiness",
     "fisker",
     "García",
@@ -145,6 +148,7 @@
     "preact",
     "Premade",
     "prettier's",
+    "projectservice",
     "quasis",
     "Quickstart",
     "Rebecca",

diff --git a/.github/actions/breaking-pr-check/index.js b/.github/actions/breaking-pr-check/index.js
@@ -1,5 +1,5 @@
 // @ts-check
-/* eslint-disable jsdoc/no-types */
+/* eslint-disable jsdoc/no-types, @typescript-eslint/no-require-imports */
 
 const core = require('@actions/core');
 const github = require('@actions/github');

diff --git a/.github/workflows/ci.yml b/.github/workflows/ci.yml
@@ -148,7 +148,7 @@ jobs:
       - name: Build
         uses: ./.github/actions/prepare-build
 
-      - name: Run integrations tests
+      - name: Run integration tests
         run: yarn test-integration
         env:
           CI: true
@@ -220,8 +220,8 @@ jobs:
           # Sadly 1 day is the minimum
           retention-days: 1
 
-  unit_tests_tsserver:
-    name: Run Unit Tests with Experimental TSServer
+  unit_tests_project_service:
+    name: Run Unit Tests with Project Service
     needs: [build]
     runs-on: ubuntu-latest
     strategy:
@@ -245,7 +245,7 @@ jobs:
         run: npx nx test ${{ matrix.package }} --coverage=false
         env:
           CI: true
-          TYPESCRIPT_ESLINT_EXPERIMENTAL_TSSERVER: true
+          TYPESCRIPT_ESLINT_PROJECT_SERVICE: true
 
   upload_coverage:
     name: Upload Codecov Coverage

diff --git a/.github/workflows/close-v8-issues.yml b/.github/workflows/close-v8-issues.yml
@@ -0,0 +1,18 @@
+name: Close issues related to a merged pull request based on v8 branch.
+
+on:
+  pull_request_target:
+    types: [closed]
+    branches:
+      - v8
+
+jobs:
+  close_v8_issue_on_pr_merge:
+    permissions:
+      issues: write
+    runs-on: ubuntu-latest
+    steps:
+      - name: Closes issues related to a merged pull request.
+        uses: ldez/gha-mjolnir@v1.4.1
+        env:
+          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
diff --git a/README.md b/README.md
@@ -24,9 +24,6 @@
 <p align="center">
 👆
 </p>
-<p align="center">
-  Using ESLint v9? See: <a href="https://github.com/typescript-eslint/typescript-eslint/issues/8211">ESLint v9 Support</a>.
-</p>
 <!-- markdownlint-enable MD033 -->
 
 ## Code Contributors

diff --git a/docs/developers/Custom_Rules.mdx b/docs/developers/Custom_Rules.mdx
@@ -99,6 +99,32 @@ export const rule = createRule<Options, MessageIds>({
 });
 ```
 
+#### Extra Rule Docs Types
+
+By default, rule `meta.docs` is allowed to contain only `description` and `url` as described in [ESLint's Custom Rules > Rule Structure docs](https://eslint.org/docs/latest/extend/custom-rules#rule-structure).
+Additional docs properties may be added as a type argument to `ESLintUtils.RuleCreator`:
+
+```ts
+interface MyPluginDocs {
+  recommended: boolean;
+}
+
+const createRule = ESLintUtils.RuleCreator<MyPluginDocs>(
+  name => `https://example.com/rule/${name}`,
+);
+
+createRule({
+  // ...
+  meta: {
+    docs: {
+      description: '...',
+      recommended: true,
+    },
+    // ...
+  },
+});
+```
+
 ### Undocumented Rules
 
 Although it is generally not recommended to create custom rules without documentation, if you are sure you want to do this you can use the `ESLintUtils.RuleCreator.withoutDocs` function to directly create a rule.

diff --git a/docs/getting-started/Typed_Linting.mdx b/docs/getting-started/Typed_Linting.mdx
@@ -25,7 +25,7 @@ export default tseslint.config(
   {
     languageOptions: {
       parserOptions: {
-        project: true,
+        projectService: true,
         tsconfigRootDir: import.meta.dirname,
       },
     },
@@ -42,7 +42,7 @@ For CommonJS modules and/or older versions of Node.js, [use `__dirname` or an al
 In more detail:
 
 - `tseslint.configs.recommendedTypeChecked` is another [shared configuration](../users/Shared_Configurations.mdx) we provide. This one contains recommended rules that additionally require type information.
-- `parserOptions.project: true` indicates to find the closest `tsconfig.json` for each source file (see [Parser#project](../packages/Parser.mdx#project)).
+- `parserOptions.projectService: true` indicates to ask TypeScript's type checking service for each source file's type information (see [Parser#projectService](../packages/Parser.mdx#projectService)).
 - `parserOptions.tsconfigRootDir` tells our parser the absolute path of your project's root directory (see [Parser#tsconfigRootDir](../packages/Parser.mdx#tsconfigrootdir)).
 
 </TabItem>
@@ -65,7 +65,7 @@ module.exports = {
   parser: '@typescript-eslint/parser',
   // Added lines start
   parserOptions: {
-    project: true,
+    projectService: true,
     tsconfigRootDir: __dirname,
   },
   // Added lines end
@@ -76,7 +76,7 @@ module.exports = {
 In more detail:
 
 - `plugin:@typescript-eslint/recommended-type-checked` is another [shared configuration](../users/Shared_Configurations.mdx) we provide. This one contains recommended rules that additionally require type information.
-- `parserOptions.project: true` indicates to find the closest `tsconfig.json` for each source file (see [Parser#project](../packages/Parser.mdx#project)).
+- `parserOptions.projectService: true` indicates to ask TypeScript's type checking service for each source file's type information (see [Parser#projectService](../packages/Parser.mdx#projectService)).
 - `parserOptions.tsconfigRootDir` tells our parser the absolute path of your project's root directory (see [Parser#tsconfigRootDir](../packages/Parser.mdx#tsconfigrootdir)).
 
 </TabItem>
@@ -142,7 +142,11 @@ You can read more about the rules provided by typescript-eslint in our [rules do
 
 ### Can I customize the TSConfig used for typed linting?
 
-The `project` option can be turned on with either:
+Yes, but it's not recommended in most configurations.
+`parserOptions.projectService` uses the same "project service" APIs used by editors such as VS Code to generate TypeScript's type information.
+Using a different TSConfig runs the risk of providing different types for typed linting than what your editor or `tsc` see.
+
+If you absolutely must, the `parserOptions.project` option can be used instead of `parserOptions.projectService` with either:
 
 - `true`: to always use `tsconfig.json`s nearest to source files
 - `string | string[]`: any number of glob paths to match TSConfig files relative to `parserOptions.tsconfigRootDir`, or the current working directory if that is not provided
@@ -182,7 +186,7 @@ module.exports = {
 </TabItem>
 </Tabs>
 
-See [the `@typescript-eslint/parser` docs for more details](../packages/Parser.mdx#project).
+See [the `@typescript-eslint/parser` `project` docs for more details](../packages/Parser.mdx#project).
 
 :::note
 If your project is a multi-package monorepo, see [our docs on configuring a monorepo](../troubleshooting/typed-linting/Monorepos.mdx).
@@ -203,7 +207,8 @@ export default tseslint.config(
   {
     languageOptions: {
       parserOptions: {
-        project: true,
+        projectService: true,
+        tsconfigRootDir: import.meta.name,
       },
     },
   },
@@ -254,7 +259,7 @@ If you use type-aware rules from other plugins, you will need to manually disabl
 ### How is performance?
 
 Typed rules come with a catch.
-By including `parserOptions.project` in your config, you incur the performance penalty of asking TypeScript to do a build of your project before ESLint can do its linting.
+By using typed linting in your config, you incur the performance penalty of asking TypeScript to do a build of your project before ESLint can do its linting.
 For small projects this takes a negligible amount of time (a few seconds or less); for large projects, it can take longer.
 
 Most of our users do not mind this cost as the power and safety of type-aware static analysis rules is worth the tradeoff.

diff --git a/docs/maintenance/Issues.mdx b/docs/maintenance/Issues.mdx
@@ -163,7 +163,7 @@ For enhancements meant to limit which kinds of nodes the rule targets, mark the
 #### 🚀 New Rules
 
 We're generally accepting of new rules that meet the above feature request criteria.
-The biggest exception is rules that can roughly be implemented with [`@typescript-eslint/ban-types`](/rules/ban-types) and/or [`no-restricted-syntax`](https://eslint.org/docs/latest/rules/no-restricted-syntax).
+The biggest exception is rules that can roughly be implemented with [`@typescript-eslint/no-restricted-types`](/rules/no-restricted-types) and/or [`no-restricted-syntax`](https://eslint.org/docs/latest/rules/no-restricted-syntax).
 
 ## Pruning Old Issues