Jul 31, 2024 · Apr 15, 2024 · Apr 15, 2024 · Apr 19, 2024 · Apr 19, 2024 · Apr 19, 2024
diff --git a/.cspell.json b/.cspell.json
  "words": [
    "Airbnb",
    "Airbnb's",
    "ambiently",
    "allowdefaultproject",
    "allowdefaultprojectforfiles",
    "ambiently",
    "Arka",
    "esquery",
    "esrecurse",
    "estree",
    "extrafileextensions",
    "falsiness",
    "fisker",
    "García",
    "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
 // @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
      - name: Build
        uses: ./.github/actions/prepare-build

      - name: Runintegrations tests
      - name: Runintegration tests
        run: yarn test-integration
        env:
          CI: true
          # Sadly 1 day is the minimum
          retention-days: 1

 unit_tests_tsserver:
    name: Run Unit Tests withExperimental TSServer
 unit_tests_project_service:
    name: Run Unit Tests withProject Service
    needs: [build]
    runs-on: ubuntu-latest
    strategy:
        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
 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
 <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
 });
 ```

 #### 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
  {
    languageOptions: {
      parserOptions: {
 project: true,
 projectService: true,
        tsconfigRootDir: import.meta.dirname,
      },
    },
 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 tofind the closest `tsconfig.json`for each source file(see [Parser#project](../packages/Parser.mdx#project)).
 - `parserOptions.projectService: true` indicates toask TypeScript's type checking servicefor 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>
  parser: '@typescript-eslint/parser',
  // Added lines start
  parserOptions: {
 project: true,
 projectService: true,
    tsconfigRootDir: __dirname,
  },
  // Added lines end
 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 tofind the closest `tsconfig.json`for each source file(see [Parser#project](../packages/Parser.mdx#project)).
 - `parserOptions.projectService: true` indicates toask TypeScript's type checking servicefor 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>

 ### 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
 </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).
  {
    languageOptions: {
      parserOptions: {
        project: true,
        projectService: true,
        tsconfigRootDir: import.meta.name,
      },
    },
  },
 ### How is performance?

 Typed rules come with a catch.
 Byincluding `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.
 Byusing 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
 #### 🚀 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
Original file line number	Diff line number	Diff line change
Expand Up		@@ -49,6 +49,8 @@
		"words": [
		"Airbnb",
		"Airbnb's",
		"ambiently",
		"allowdefaultproject",
		"allowdefaultprojectforfiles",
		"ambiently",
		"Arka",
Expand DownExpand Up		@@ -98,6 +100,7 @@
		"esquery",
		"esrecurse",
		"estree",
		"extrafileextensions",
		"falsiness",
		"fisker",
		"García",
Expand DownExpand Up		@@ -145,6 +148,7 @@
		"preact",
		"Premade",
		"prettier's",
		"projectservice",
		"quasis",
		"Quickstart",
		"Rebecca",
Expand Down
Original file line number	Diff line number	Diff line change
		@@ -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');
Expand Down
Original file line number	Diff line number	Diff line change
Expand Up		@@ -148,7 +148,7 @@ jobs:
		- name: Build
		uses: ./.github/actions/prepare-build

		- name: Runintegrations tests
		- name: Runintegration tests
		run: yarn test-integration
		env:
		CI: true
Expand DownExpand Up		@@ -220,8 +220,8 @@ jobs:
		# Sadly 1 day is the minimum
		retention-days: 1

		unit_tests_tsserver:
		name: Run Unit Tests withExperimental TSServer
		unit_tests_project_service:
		name: Run Unit Tests withProject Service
		needs: [build]
		runs-on: ubuntu-latest
		strategy:
Expand All		@@ -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
Expand Down
Original file line number	Diff line number	Diff line change
		@@ -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 }}
Original file line number	Diff line number	Diff line change
Expand Up		@@ -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
Expand Down
Original file line number	Diff line number	Diff line change
Expand Up		@@ -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.
Expand Down
Original file line number	Diff line number	Diff line change
Expand Up		@@ -25,7 +25,7 @@ export default tseslint.config(
		{
		languageOptions: {
		parserOptions: {
		project: true,
		projectService: true,
		tsconfigRootDir: import.meta.dirname,
		},
		},
Expand All		@@ -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 tofind the closest `tsconfig.json`for each source file(see [Parser#project](../packages/Parser.mdx#project)).
		- `parserOptions.projectService: true` indicates toask TypeScript's type checking servicefor 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>
Expand All		@@ -65,7 +65,7 @@ module.exports = {
		parser: '@typescript-eslint/parser',
		// Added lines start
		parserOptions: {
		project: true,
		projectService: true,
		tsconfigRootDir: __dirname,
		},
		// Added lines end
Expand All		@@ -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 tofind the closest `tsconfig.json`for each source file(see [Parser#project](../packages/Parser.mdx#project)).
		- `parserOptions.projectService: true` indicates toask TypeScript's type checking servicefor 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>
Expand DownExpand Up		@@ -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
Expand DownExpand Up		@@ -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).
Expand All		@@ -203,7 +207,8 @@ export default tseslint.config(
		{
		languageOptions: {
		parserOptions: {
		project: true,
		projectService: true,
		tsconfigRootDir: import.meta.name,
		},
		},
		},
Expand DownExpand Up		@@ -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.
		Byincluding `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.
		Byusing 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.
Expand Down
Original file line number	Diff line number	Diff line change
Expand Up		@@ -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

Expand Down