Merge branch 'main'

.github/ISSUE_TEMPLATE/06-bug-report-other.yaml

@@ -20,7 +20,11 @@ body:
         - label: I have [read the FAQ](https://typescript-eslint.io/linting/troubleshooting) and my problem is not listed.
           required: true
   - type: markdown
-    id: complexity-note
+    attributes:
+      value: |
+        **All typescript-eslint bug reports need an isolated reproduction** we can clone locally and get running without other projects or existing knowledge of your project.
+        If you can't provide one, your report will likely be closed without action.
+  - type: markdown
     attributes:
       value: |
         ### Note For Complex Issues

.github/workflows/lock.yml

@@ -14,8 +14,9 @@ jobs:
 
     runs-on: ubuntu-latest
     steps:
-      - uses: dessant/lock-threads@v4
+      - uses: dessant/lock-threads@v5.0.1
         with:
+          add-issue-labels: 'locked due to age'
           github-token: ${{ github.token }}
           issue-inactive-days: '7'
           issue-lock-reason: 'resolved'

.github/workflows/pr-labels.yml

@@ -0,0 +1,25 @@
+name: Pull Request Labels
+
+on:
+  pull_request:
+    types: [labeled, opened, synchronize, unlabeled]
+
+jobs:
+  label:
+    runs-on: ubuntu-latest
+    permissions:
+      issues: write
+      pull-requests: write
+    steps:
+      - id: changed-stable-configs
+        uses: tj-actions/changed-files@v44.5.2
+        with:
+          files: packages/{eslint-plugin,typescript-eslint}/src/configs/{recommended,stylistic}*
+      - if: steps.changed-stable-configs.outputs.any_changed == 'true'
+        uses: mheap/github-action-required-labels@v5.4.1
+        with:
+          add_comment: true
+          count: 1
+          labels: breaking change
+          message: '🤖 Beep boop! PRs that change our stable preset configs must be labeled with `breaking change`.'
+          mode: minimum

docs/Contributing.mdx

@@ -16,6 +16,6 @@ If you're new to open source, you may also find the [How to Contribute to Open S
 
 ## Next Steps
 
-1. [Finding or opening an issue](./contributing/Issues.mdx): In the issue tab, find the pr currently tagged with `accepting prs` or create a new issue.
-2. [Setting up a local environment](./contributing/Local_Development.mdx): Let's learn how to set up the local environment to start development.
-3. [Making a PR](./contributing/Pull_Requests.mdx): you've got changes locally that address an issue, take a look at that topic.
+1. [Finding or opening an issue](./contributing/Issues.mdx): In the issue tab, finding or creating an issue to work on.
+2. [Setting up a local environment](./contributing/Local_Development.mdx): Learning how to set up the local environment to start development.
+3. [Making a PR](./contributing/Pull_Requests.mdx): Sending in your changes to resolve an accepted issue.

docs/contributing/Issues.mdx

@@ -34,6 +34,13 @@ We've found in the past that they result in accidental ["licked cookie"](https:/
 If an issue has been marked as `accepting prs` and an open PR does not exist, feel free to send a PR.
 You don't need to ask for permission.
 
+## Finding Issues
+
+Consider searching through:
+
+1. [Unassigned user-facing marked as `accepting prs` and `good first issue`](https://github.com/typescript-eslint/typescript-eslint/issues?q=is%3Aopen+is%3Aissue+label%3A%22good+first+issue%22+label%3A%22accepting+prs%22+-label%3A%22repo+maintenance%22+no%3Aassignee): to find issues marked as good for a first-timer
+2. [Unassigned user-facing marked as `accepting prs` without `good first issue`](https://github.com/typescript-eslint/typescript-eslint/issues?q=is%3Aopen+is%3Aissue+label%3A%22accepting+prs%22+-label%3A%22good+first+issue%22+-label%3A%22repo+maintenance%22+no%3Aassignee): once you've finished a few issues, to find more intermediate-level issues
+
 ## Questions and Support Requests
 
 The issue tracker is not an appropriate place for questions or support requests.

docs/contributing/Local_Development.mdx

@@ -61,23 +61,6 @@ You can run `yarn test` in any package to run its tests.
 
 > [VS Code launch tasks](https://code.visualstudio.com/docs/editor/tasks) tasks are provided that allow [visual debugging](https://code.visualstudio.com/docs/editor/debugging) tests.
 
-#### Code Coverage
-
-We aim for 100% code coverage in all PRs when possible, except in the `website/` package.
-Coverage reports are generated locally whenever `yarn test` is run.
-
-The `codecov` bot should also comment on your PR with the percentage, as well as links to the line-by-line coverage of each file touched by your PR.
-
-#### Granular Unit Tests
-
-Most tests in most packages are set up as small, self-contained unit tests.
-We generally prefer that to keep tests and their failure reports granular.
-
-For rule tests we recommend, when reasonable:
-
-- Including both `valid` and `invalid` code changes in most PRs that affect rule behavior
-- Limiting to one error per `invalid` case
-
 ### Type Checking
 
 All code should pass TypeScript type checking.

docs/contributing/Pull_Requests.mdx

@@ -25,7 +25,26 @@ Please don't:
 - Comment on a closed PR
   - Reasoning: It is much easier for maintainers to not lose track of things if they are posted as issues. If you think there's a bug in typescript-eslint, the right way to ask is to [file a new issue](https://github.com/typescript-eslint/typescript-eslint/issues/new/choose). The issue templates include helpful & necessary practices such as making sure you're on the latest version of all our packages. You can provide the link to the relevant PR to add more context.
 
-### Raising a PR
+### Testing Changes
+
+#### Code Coverage
+
+We aim for 100% code coverage in all PRs when possible, except in the `website/` package.
+Coverage reports are generated locally whenever `yarn test` is run.
+
+The `codecov` bot also comments on each PR with its percentage, as well as links to the line-by-line coverage of each file touched by the PR.
+
+#### Granular Unit Tests
+
+Most tests in most packages are set up as small, self-contained unit tests.
+We generally prefer that to keep tests and their failure reports granular.
+
+For rule tests we recommend, when reasonable:
+
+- Including both `valid` and `invalid` code changes in most PRs that affect rule behavior
+- Limiting to one error per `invalid` case
+
+### Raising the PR
 
 Once your changes are ready, you can raise a PR! 🙌
 The title of your PR should match the following format:
@@ -84,6 +103,14 @@ Once you've addressed all our feedback by making code changes and/or started a f
 
 Once the feedback is addressed, and the PR is approved, we'll ensure the branch is up to date with `main`, and merge it for you.
 
+#### Updating Over Time
+
+You generally don't need to keep merging commits from `main` into your PR branch.
+If you see merge conflicts or other intersections that worry you, then you can preemptively - but that's optional.
+
+If we think merge conflicts need to be resolved in order to merge and/or review a PR, we might do that for you as a courtesy _if_ we have time.
+If not, we may ask you to.
+
 ### Asking Questions
 
 If you need help and/or have a question, posting a comment in the PR is a great way to do so.

docs/maintenance/Contributor_Tiers.mdx

@@ -95,7 +95,10 @@ We treat both the creation and review of issues and PRs along the rough scale of
         <a href="https://github.com/typescript-eslint/typescript-eslint/pull/6976">
           #6976
         </a>
-        , <a href="https://github.com/typescript-eslint/typescript-eslint/issues/6992">#6992</a>
+        ,{' '}
+        <a href="https://github.com/typescript-eslint/typescript-eslint/issues/6992">
+          #6992
+        </a>
       </td>
     </tr>
     <tr>
@@ -106,7 +109,10 @@ We treat both the creation and review of issues and PRs along the rough scale of
         <a href="https://github.com/typescript-eslint/typescript-eslint/pull/6780">
           #6780
         </a>
-        , <a href="https://github.com/typescript-eslint/typescript-eslint/pull/6910">#6910</a>
+        ,{' '}
+        <a href="https://github.com/typescript-eslint/typescript-eslint/pull/6910">
+          #6910
+        </a>
       </td>
     </tr>
     <tr>
@@ -117,7 +123,10 @@ We treat both the creation and review of issues and PRs along the rough scale of
         <a href="https://github.com/typescript-eslint/typescript-eslint/pull/6107">
           #6107
         </a>
-        , <a href="https://github.com/typescript-eslint/typescript-eslint/pull/6907">#6907</a>
+        ,{' '}
+        <a href="https://github.com/typescript-eslint/typescript-eslint/pull/6907">
+          #6907
+        </a>
       </td>
     </tr>
     <tr>
@@ -128,7 +137,10 @@ We treat both the creation and review of issues and PRs along the rough scale of
         <a href="https://github.com/typescript-eslint/typescript-eslint/pull/6084">
           #6084
         </a>
-        , <a href="https://github.com/typescript-eslint/typescript-eslint/pull/6777">#6777</a>
+        ,{' '}
+        <a href="https://github.com/typescript-eslint/typescript-eslint/pull/6777">
+          #6777
+        </a>
       </td>
     </tr>
   </tbody>

docs/maintenance/Releases.mdx

@@ -50,7 +50,7 @@ In parallel to the general PR flow of the major version:
 
 In parallel to the shared config changes work, make sure to test out the beta version on popular community projects willing to try it out.
 
-1. Create a pinned issue offering to try out the new version's beta for consumers [example: [Try out v6 beta on various important community repos](https://github.com/typescript-eslint/typescript-eslint/issues/6760)]
+1. Create a pinned issue offering to try out the new version's beta for consumers [example: [Try out v8 beta on various influential community repos](https://github.com/typescript-eslint/typescript-eslint/issues/9141)]
    - Ask each community project if they'd be interested in trying out the new version, such as in their Discord or on their issue tracker.
    - Each community project that's indicated willingness to receive a PR should have one.
 1. Once the proposed _Shared Config Changes_ are merged into the `v${major}` branch, send a draft PR to each project with the new beta version.

docs/maintenance/issues/Rule_Deprecations.mdx → docs/maintenance/issues/Rule_Deprecations_And_Deletions.mdx

@@ -1,6 +1,6 @@
 ---
-id: rule-deprecations
-title: Rule Deprecations
+id: rule-deprecations-and-deletions
+title: Rule Deprecations, Renames, And Deletions
 ---
 
 Sometimes a rule that used to be 👍 does not age well and becomes 👎.
@@ -14,12 +14,12 @@ In these cases, we aim to remove the old rule with minimal user disruption.
 
 ## Filing the Issue
 
-Rule deprecations can be filed as a [new issue bypassing templates](https://github.com/typescript-eslint/typescript-eslint/issues/new).
+Rule deprecations and renames can be filed as a [new issue bypassing templates](https://github.com/typescript-eslint/typescript-eslint/issues/new).
 
 Provide it an `## Overview` containing:
 
 - The rule name & link to its documentation page
-- A clear explanation of why you believe it should be deprecated
+- A clear explanation of why you believe it should be deprecated and/or renamed
 - Whether it exists in popular configs such as `eslint-config-airbnb-typescript` and `eslint-config-standard-with-typescript`
 - Sourcegraph queries showing how often it appears in user configs
 
@@ -30,5 +30,8 @@ Provide it an `## Overview` containing:
 1. In any minor/patch version, add [rule `meta` properties](https://eslint.org/docs/latest/developer-guide/working-with-rules#rule-basics):
    - `deprecated: true`
    - `replacedBy`, if applicable
-2. In the next major version, you may delete the rule
-   - If the rule is relatively popular with users, consider leaving a documentation page as a tombstone pointing to the new relevant rule or docs (see [`camelcase`](/rules/camelcase/) as an example)
+2. Search through open issues and PRs, and update the name in them accordingly:
+   - Deletions: close them with a link to the issue and deprecation PR
+   - Renames: update their title and explicitly mention in a comment that the rule has been renamed
+3. In the next major version, you may delete the deprecated rule
+   - Leave a documentation page as a tombstone pointing to the new relevant rule or docs (see [`camelcase`](/rules/camelcase) as an example)

docs/maintenance/pull-requests/Dependency_Version_Upgrades.mdx

@@ -134,6 +134,7 @@ We generally start the process of supporting a new TypeScript version just after
    - Whenever a PR is merged, change the respective heading's emoji from 🏗 to ✅
 1. Create a PR with a title like `feat: update TypeScript to X.Y-rc` and the following changes:
    - In the root `package.json`, add `|| X.Y.1-rc2` to the `devDependency` on `typescript`
+   - In the parser's `getLib`, update the `switch (target)` and its preceding comment as needed (see [#6782](https://github.com/typescript-eslint/typescript-eslint/pull/6782))
    - Change the `SUPPORTED_TYPESCRIPT_VERSIONS` constant's `<` version to the next version of TypeScript
    - Change the `SUPPORTED_PRERELEASE_RANGES` constant to equal `['X.Y.1-rc']`
    - Rename and update `patches/typescript*` to the new TypeScript version

docs/packages/ESLint_Plugin.mdx

@@ -5,6 +5,8 @@ sidebar_label: eslint-plugin
 
 # `@typescript-eslint/eslint-plugin`
 
+<PackageLink packageName="eslint-plugin" scope="@typescript-eslint" />
+
 > The TypeScript plugin for ESLint. ✨
 
 :::info

docs/packages/ESLint_Plugin_TSLint.mdx

@@ -5,6 +5,8 @@ sidebar_label: eslint-plugin-tslint
 
 # `@typescript-eslint/eslint-plugin-tslint`
 
+<PackageLink packageName="eslint-plugin-tslint" scope="@typescript-eslint" />
+
 > ESLint plugin that allows running TSLint rules within ESLint to help you migrate from TSLint to ESLint. ✨
 
 :::caution

docs/packages/Parser.mdx

@@ -3,8 +3,13 @@ id: parser
 sidebar_label: parser
 ---
 
+import Tabs from '@theme/Tabs';
+import TabItem from '@theme/TabItem';
+
 # `@typescript-eslint/parser`
 
+<PackageLink packageName="parser" scope="@typescript-eslint" />
+
 > An [ESLint parser](https://eslint.org/docs/user-guide/configuring/plugins#specifying-parser) used to parse TypeScript code into ESLint-compatible nodes, as well as provide backing TypeScript programs. ✨
 
 This is necessary because TypeScript produces a different, incompatible AST format to the one that ESLint requires to work.
@@ -276,7 +281,25 @@ For an option that allows linting files outside of your TSConfig file(s), see [`
 Specifies using TypeScript APIs to generate type information for rules.
 It will automatically detect the TSConfig for each file (like `project: true`), and will also allow type information to be computed for JavaScript files without the `allowJs` compiler option (unlike `project: true`).
 
-```js
+<Tabs groupId="eslint-config">
+<TabItem value="Flat Config">
+
+```js title="eslint.config.js"
+export default [
+  {
+    languageOptions: {
+      parserOptions: {
+        projectService: true,
+      },
+    },
+  },
+];
+```
+
+</TabItem>
+<TabItem value="Legacy Config">
+
+```js title=".eslintrc.js"
 module.exports = {
   parser: '@typescript-eslint/parser',
   parserOptions: {
@@ -285,6 +308,9 @@ module.exports = {
 };
 ```
 
+</TabItem>
+</Tabs>
+
 **This setting or [`project`](#project) are required to use [rules which require type information](../getting-started/Typed_Linting.mdx)**.
 
 This option brings two main benefits over the older `project`:
@@ -383,6 +409,24 @@ declare function createProgram(
 
 Example usage:
 
+<Tabs groupId="eslint-config">
+<TabItem value="Flat Config">
+
+```js title="eslint.config.js"
+import * as parser from '@typescript-eslint/parser';
+
+export default [
+  {
+    parserOptions: {
+      programs: [parser.createProgram('tsconfig.json')],
+    },
+  },
+];
+```
+
+</TabItem>
+<TabItem value="Legacy Config">
+
 ```js title=".eslintrc.js"
 const parser = require('@typescript-eslint/parser');
 
@@ -392,3 +436,34 @@ module.exports = {
   },
 };
 ```
+
+</TabItem>
+</Tabs>
+
+### `withoutProjectParserOptions(parserOptions)`
+
+Removes options that prompt the parser to parse the project with type information.
+In other words, you can use this if you are invoking the parser directly, to ensure that one file will be parsed in isolation, which is much faster.
+
+This is useful in cases where you invoke the parser directly, such as in an ESLint plugin context.
+
+```ts
+declare function withoutProjectParserOptions(
+  options: TSESTreeOptions,
+): TSESTreeOptions;
+```
+
+Example usage:
+
+```js title="somePlugin.js"
+const parser = require('@typescript-eslint/parser');
+
+function parse(path, content, context) {
+  const contextParserOptions = context.languageOptions?.parserOptions ?? {};
+  const parserOptions =
+    parser.withoutProjectParserOptions(contextParserOptions);
+
+  // Do something with the cleaned-up options eventually, such as invoking the parser
+  parser.parseForESLint(content, parserOptions);
+}
+```

docs/packages/Rule_Tester.mdx

@@ -7,6 +7,8 @@ import CodeBlock from '@theme/CodeBlock';
 
 # `@typescript-eslint/rule-tester`
 
+<PackageLink packageName="rule-tester" scope="@typescript-eslint" />
+
 > A utility for testing ESLint rules
 
 This is a fork of ESLint's built-in `RuleTester` to provide some better types and additional features for testing TypeScript rules.

docs/packages/Scope_Manager.mdx

@@ -5,6 +5,8 @@ sidebar_label: scope-manager
 
 # `@typescript-eslint/scope-manager`
 
+<PackageLink packageName="scope-manager" scope="@typescript-eslint" />
+
 > A fork of [`eslint-scope`](https://github.com/eslint/eslint-scope), enhanced to support TypeScript functionality. ✨
 
 A "scope analyser" traverses an AST and builds a model of how variables (and in our case, types) are defined and consumed by the source code.

docs/packages/TypeScript_ESLint.mdx

@@ -8,6 +8,8 @@ import TabItem from '@theme/TabItem';
 
 # `typescript-eslint`
 
+<PackageLink packageName="typescript-eslint" />
+
 > Tooling which enables you to use TypeScript with ESLint
 
 This package is the main entrypoint that you can use to consume our tooling with ESLint.