@rushstack/eslint-config 4.2.0 → 4.4.0

package/CHANGELOG.json

@@ -1,6 +1,58 @@
 {
   "name": "@rushstack/eslint-config",
   "entries": [
+    {
+      "version": "4.4.0",
+      "tag": "@rushstack/eslint-config_v4.4.0",
+      "date": "Thu, 26 Jun 2025 18:57:04 GMT",
+      "comments": {
+        "minor": [
+          {
+            "comment": "Add flat config compatible versions of profiles and mixins. These are located under the `/flat/*` path."
+          }
+        ],
+        "dependency": [
+          {
+            "comment": "Updating dependency \"@rushstack/eslint-patch\" to `1.12.0`"
+          },
+          {
+            "comment": "Updating dependency \"@rushstack/eslint-plugin\" to `0.19.0`"
+          },
+          {
+            "comment": "Updating dependency \"@rushstack/eslint-plugin-packlets\" to `0.12.0`"
+          },
+          {
+            "comment": "Updating dependency \"@rushstack/eslint-plugin-security\" to `0.11.0`"
+          }
+        ]
+      }
+    },
+    {
+      "version": "4.3.0",
+      "tag": "@rushstack/eslint-config_v4.3.0",
+      "date": "Tue, 11 Mar 2025 02:12:33 GMT",
+      "comments": {
+        "minor": [
+          {
+            "comment": "Bump the `@typescript-eslint/*` packages to add support for TypeScript 5.8."
+          }
+        ],
+        "dependency": [
+          {
+            "comment": "Updating dependency \"@rushstack/eslint-patch\" to `1.11.0`"
+          },
+          {
+            "comment": "Updating dependency \"@rushstack/eslint-plugin\" to `0.18.0`"
+          },
+          {
+            "comment": "Updating dependency \"@rushstack/eslint-plugin-packlets\" to `0.11.0`"
+          },
+          {
+            "comment": "Updating dependency \"@rushstack/eslint-plugin-security\" to `0.10.0`"
+          }
+        ]
+      }
+    },
     {
       "version": "4.2.0",
       "tag": "@rushstack/eslint-config_v4.2.0",

package/CHANGELOG.md

@@ -1,6 +1,20 @@
 # Change Log - @rushstack/eslint-config
 
-This log was last generated on Sat, 01 Mar 2025 07:23:16 GMT and should not be manually modified.
+This log was last generated on Thu, 26 Jun 2025 18:57:04 GMT and should not be manually modified.
+
+## 4.4.0
+Thu, 26 Jun 2025 18:57:04 GMT
+
+### Minor changes
+
+- Add flat config compatible versions of profiles and mixins. These are located under the `/flat/*` path.
+
+## 4.3.0
+Tue, 11 Mar 2025 02:12:33 GMT
+
+### Minor changes
+
+- Bump the `@typescript-eslint/*` packages to add support for TypeScript 5.8.
 
 ## 4.2.0
 Sat, 01 Mar 2025 07:23:16 GMT

package/flat/mixins/friendly-locals.js

@@ -0,0 +1,90 @@
+// Copyright (c) Microsoft Corporation. All rights reserved. Licensed under the MIT license.
+// See LICENSE in the project root for license information.
+
+// For the first 5 years of Rush, our lint rules required explicit types for most declarations
+// such as function parameters, function return values, and exported variables.  Although more verbose,
+// declaring types (instead of relying on type inference) encourages engineers to create interfaces
+// that inspire discussions about data structure design.  It also makes source files easier
+// to understand for code reviewers who may be unfamiliar with a particular project.  Once developers get
+// used to the extra work of declaring types, it turns out to be a surprisingly popular practice.
+//
+// However in 2020, to make adoption easier for existing projects, this rule was relaxed.  Explicit
+// type declarations are now optional for local variables (although still required in other contexts).
+// See this GitHub issue for background:
+//
+//  https://github.com/microsoft/rushstack/issues/2206
+//
+// If you are onboarding a large existing code base, this new default will make adoption easier.
+//
+// On the other hand, if your top priority is to make source files more friendly for other
+// people to read, enable the "@rushstack/eslint-config/mixins/friendly-locals" mixin.
+// It will restore the requirement that local variables should have explicit type declarations.
+//
+// IMPORTANT: Mixins must be included in your ESLint configuration AFTER the profile
+
+const typescriptEslintPlugin = require('@typescript-eslint/eslint-plugin');
+
+module.exports = [
+  {
+    files: ['**/*.ts', '**/*.tsx'],
+    plugins: {
+      '@typescript-eslint': typescriptEslintPlugin
+    },
+    rules: {
+      '@rushstack/typedef-var': 'off', // <--- disabled by the mixin
+
+      '@typescript-eslint/typedef': [
+        'warn',
+        {
+          arrayDestructuring: false,
+          arrowParameter: false,
+          memberVariableDeclaration: true,
+          objectDestructuring: false,
+          parameter: true,
+          propertyDeclaration: true,
+
+          variableDeclaration: true, // <--- reenabled by the mixin
+
+          variableDeclarationIgnoreFunction: true
+        }
+      ]
+    }
+  },
+  {
+    files: [
+      // Test files
+      '**/*.test.ts',
+      '**/*.test.tsx',
+      '**/*.spec.ts',
+      '**/*.spec.tsx',
+
+      // Facebook convention
+      '**/__mocks__/**/*.ts',
+      '**/__mocks__/**/*.tsx',
+      '**/__tests__/**/*.ts',
+      '**/__tests__/**/*.tsx',
+
+      // Microsoft convention
+      '**/test/**/*.ts',
+      '**/test/**/*.tsx'
+    ],
+    plugins: {
+      '@typescript-eslint': typescriptEslintPlugin
+    },
+    rules: {
+      '@typescript-eslint/typedef': [
+        'warn',
+        {
+          arrayDestructuring: false,
+          arrowParameter: false,
+          memberVariableDeclaration: true,
+          objectDestructuring: false,
+          parameter: true,
+          propertyDeclaration: true,
+          variableDeclaration: false, // <--- special case for test files
+          variableDeclarationIgnoreFunction: true
+        }
+      ]
+    }
+  }
+];

package/flat/mixins/packlets.js

@@ -0,0 +1,21 @@
+// Copyright (c) Microsoft Corporation. All rights reserved. Licensed under the MIT license.
+// See LICENSE in the project root for license information.
+
+// This mixin implements the "packlet" formalism for organizing source files.
+// For more information, see the documentation here:
+// https://www.npmjs.com/package/@rushstack/eslint-plugin-packlets
+//
+// IMPORTANT: Mixins must be included in your ESLint configuration AFTER the profile
+
+const rushstackPackletsEslintPlugin = require('@rushstack/eslint-plugin-packlets');
+
+module.exports = {
+  files: ['**/*.ts', '**/*.tsx'],
+  plugins: {
+    '@rushstack/packlets': rushstackPackletsEslintPlugin
+  },
+  rules: {
+    '@rushstack/packlets/mechanics': 'warn',
+    '@rushstack/packlets/circular-deps': 'warn'
+  }
+};

package/flat/mixins/react.js

@@ -0,0 +1,77 @@
+// Copyright (c) Microsoft Corporation. All rights reserved. Licensed under the MIT license.
+// See LICENSE in the project root for license information.
+
+// This mixin applies some additional checks for projects using the React library.  For more information,
+// please see the README.md for "@rushstack/eslint-config".
+//
+// IMPORTANT: Mixins must be included in your ESLint configuration AFTER the profile
+
+const reactEslintPlugin = require('eslint-plugin-react');
+
+module.exports = [
+  {
+    files: ['**/*.ts', '**/*.tsx'],
+    plugins: {
+      react: reactEslintPlugin
+    },
+    settings: {
+      react: {
+        // The default value is "detect".  Automatic detection works by loading the entire React library
+        // into the linter's process, which is inefficient.  It is recommended to specify the version
+        // explicity.  For details, see README.md for "@rushstack/eslint-config".
+        version: 'detect'
+      }
+    },
+    rules: {
+      // RATIONALE:         When React components are added to an array, they generally need a "key".
+      'react/jsx-key': 'warn',
+
+      // RATIONALE:         Catches a common coding practice that significantly impacts performance.
+      'react/jsx-no-bind': 'warn',
+
+      // RATIONALE:         Catches a common coding mistake.
+      'react/jsx-no-comment-textnodes': 'warn',
+
+      // RATIONALE:         Security risk.
+      'react/jsx-no-target-blank': 'warn',
+
+      // RATIONALE:         Fixes the no-unused-vars rule to make it compatible with React
+      'react/jsx-uses-react': 'warn',
+
+      // RATIONALE:         Fixes the no-unused-vars rule to make it compatible with React
+      'react/jsx-uses-vars': 'warn',
+
+      // RATIONALE:         Catches a common coding mistake.
+      'react/no-children-prop': 'warn',
+
+      // RATIONALE:         Catches a common coding mistake.
+      'react/no-danger-with-children': 'warn',
+
+      // RATIONALE:         Avoids usage of deprecated APIs.
+      //
+      // Note that the set of deprecated APIs is determined by the "react.version" setting.
+      'react/no-deprecated': 'warn',
+
+      // RATIONALE:         Catches a common coding mistake.
+      'react/no-direct-mutation-state': 'warn',
+
+      // RATIONALE:         Catches some common coding mistakes.
+      'react/no-unescaped-entities': 'warn',
+
+      // RATIONALE:         Avoids a potential performance problem.
+      'react/no-find-dom-node': 'warn',
+
+      // RATIONALE:         Deprecated API.
+      'react/no-is-mounted': 'warn',
+
+      // RATIONALE:         Deprecated API.
+      'react/no-render-return-value': 'warn',
+
+      // RATIONALE:         Deprecated API.
+      'react/no-string-refs': 'warn',
+
+      // RATIONALE:         Improves syntax for some cases that are not already handled by Prettier.
+      'react/self-closing-comp': 'warn'
+    }
+  }
+];

package/flat/mixins/tsdoc.js

@@ -0,0 +1,21 @@
+// Copyright (c) Microsoft Corporation. All rights reserved. Licensed under the MIT license.
+// See LICENSE in the project root for license information.
+
+// This mixin validates code comments to ensure that they follow the TSDoc standard.  For more
+// information please see the README.md for @rushstack/eslint-config.
+//
+// IMPORTANT: Mixins must be included in your ESLint configuration AFTER the profile
+
+const tsdocEslintPlugin = require('eslint-plugin-tsdoc');
+
+module.exports = [
+  {
+    files: ['**/*.ts', '**/*.tsx'],
+    plugins: {
+      tsdoc: tsdocEslintPlugin
+    },
+    rules: {
+      'tsdoc/syntax': 'warn'
+    }
+  }
+];

package/flat/patch/eslint-bulk-suppressions.js

@@ -0,0 +1,4 @@
+// Copyright (c) Microsoft Corporation. All rights reserved. Licensed under the MIT license.
+// See LICENSE in the project root for license information.
+
+require('@rushstack/eslint-patch/eslint-bulk-suppressions');

package/flat/profile/_common.js

@@ -0,0 +1,777 @@
+// Copyright (c) Microsoft Corporation. All rights reserved. Licensed under the MIT license.
+// See LICENSE in the project root for license information.
+
+// Rule severity guidelines
+// ------------------------
+//
+// Errors are generally printed in red, and may prevent other build tasks from running (e.g. unit tests).
+// Developers should never ignore errors.  Warnings are generally printed in yellow, and do not block local
+// development, although they must be fixed/suppressed before merging.  Developers will commonly ignore warnings
+// until their feature is working.
+//
+// Rules that should be a WARNING:
+// - An issue that is very common in partially implemented work (e.g. missing type declaration)
+// - An issue that "keeps things nice" but otherwise doesn't affect the meaning of the code (e.g. naming convention)
+// - Security rules -- developers may need to temporarily introduce "insecure" expressions while debugging;
+//   if our policy forces them to suppress the lint rule, they may forget to reenable it later.
+//
+// Rules that should be an ERROR:
+// - An issue that is very likely to be a typo (e.g. "x = x;")
+// - An issue that catches code that is likely to malfunction (e.g. unterminated promise chain)
+// - An obsolete language feature that nobody should be using for any good reason
+
+const { globalIgnores } = require('eslint/config');
+const promiseEslintPlugin = require('eslint-plugin-promise');
+const typescriptEslintPlugin = require('@typescript-eslint/eslint-plugin');
+const typescriptEslintParser = require('@typescript-eslint/parser');
+const rushstackEslintPlugin = require('@rushstack/eslint-plugin');
+const rushstackSecurityEslintPlugin = require('@rushstack/eslint-plugin-security');
+const { expandNamingConventionSelectors } = require('./_macros');
+
+const commonNamingConventionSelectors = [
+  {
+    // We should be stricter about 'enumMember', but it often functions legitimately as an ad hoc namespace.
+    selectors: ['variable', 'enumMember', 'function'],
+
+    format: ['camelCase', 'UPPER_CASE', 'PascalCase'],
+    leadingUnderscore: 'allow',
+
+    filter: {
+      regex: [
+        // This is a special exception for naming patterns that use an underscore to separate two camel-cased
+        // parts.  Example:  "checkBox1_onChanged" or "_checkBox1_onChanged"
+        '^_?[a-z][a-z0-9]*([A-Z][a-z]?[a-z0-9]*)*_[a-z][a-z0-9]*([A-Z][a-z]?[a-z0-9]*)*$'
+      ]
+        .map((x) => `(${x})`)
+        .join('|'),
+      match: false
+    }
+  },
+
+  {
+    selectors: ['parameter'],
+
+    format: ['camelCase'],
+
+    filter: {
+      regex: [
+        // Silently accept names with a double-underscore prefix; we would like to be more strict about this,
+        // pending a fix for https://github.com/typescript-eslint/typescript-eslint/issues/2240
+        '^__'
+      ]
+        .map((x) => `(${x})`)
+        .join('|'),
+      match: false
+    }
+  },
+
+  // Genuine properties
+  {
+    selectors: ['parameterProperty', 'accessor'],
+    enforceLeadingUnderscoreWhenPrivate: true,
+
+    format: ['camelCase', 'UPPER_CASE'],
+
+    filter: {
+      regex: [
+        // Silently accept names with a double-underscore prefix; we would like to be more strict about this,
+        // pending a fix for https://github.com/typescript-eslint/typescript-eslint/issues/2240
+        '^__',
+        // Ignore quoted identifiers such as { "X+Y": 123 }.  Currently @typescript-eslint/naming-convention
+        // cannot detect whether an identifier is quoted or not, so we simply assume that it is quoted
+        // if-and-only-if it contains characters that require quoting.
+        '[^a-zA-Z0-9_]',
+        // This is a special exception for naming patterns that use an underscore to separate two camel-cased
+        // parts.  Example:  "checkBox1_onChanged" or "_checkBox1_onChanged"
+        '^_?[a-z][a-z0-9]*([A-Z][a-z]?[a-z0-9]*)*_[a-z][a-z0-9]*([A-Z][a-z]?[a-z0-9]*)*$'
+      ]
+        .map((x) => `(${x})`)
+        .join('|'),
+      match: false
+    }
+  },
+
+  // Properties that incorrectly match other contexts
+  // See issue https://github.com/typescript-eslint/typescript-eslint/issues/2244
+  {
+    selectors: ['property'],
+    enforceLeadingUnderscoreWhenPrivate: true,
+
+    // The @typescript-eslint/naming-convention "property" selector matches cases like this:
+    //
+    //   someLegacyApiWeCannotChange.invokeMethod({ SomeProperty: 123 });
+    //
+    // and this:
+    //
+    //   const { CONSTANT1, CONSTANT2 } = someNamespace.constants;
+    //
+    // Thus for now "property" is more like a variable than a class member.
+    format: ['camelCase', 'UPPER_CASE', 'PascalCase'],
+    leadingUnderscore: 'allow',
+
+    filter: {
+      regex: [
+        // Silently accept names with a double-underscore prefix; we would like to be more strict about this,
+        // pending a fix for https://github.com/typescript-eslint/typescript-eslint/issues/2240
+        '^__',
+        // Ignore quoted identifiers such as { "X+Y": 123 }.  Currently @typescript-eslint/naming-convention
+        // cannot detect whether an identifier is quoted or not, so we simply assume that it is quoted
+        // if-and-only-if it contains characters that require quoting.
+        '[^a-zA-Z0-9_]',
+        // This is a special exception for naming patterns that use an underscore to separate two camel-cased
+        // parts.  Example:  "checkBox1_onChanged" or "_checkBox1_onChanged"
+        '^_?[a-z][a-z0-9]*([A-Z][a-z]?[a-z0-9]*)*_[a-z][a-z0-9]*([A-Z][a-z]?[a-z0-9]*)*$'
+      ]
+        .map((x) => `(${x})`)
+        .join('|'),
+      match: false
+    }
+  },
+
+  {
+    selectors: ['method'],
+    enforceLeadingUnderscoreWhenPrivate: true,
+
+    // A PascalCase method can arise somewhat legitimately in this way:
+    //
+    // class MyClass {
+    //    public static MyReactButton(props: IButtonProps): JSX.Element {
+    //      . . .
+    //    }
+    // }
+    format: ['camelCase', 'PascalCase'],
+    leadingUnderscore: 'allow',
+
+    filter: {
+      regex: [
+        // Silently accept names with a double-underscore prefix; we would like to be more strict about this,
+        // pending a fix for https://github.com/typescript-eslint/typescript-eslint/issues/2240
+        '^__',
+        // This is a special exception for naming patterns that use an underscore to separate two camel-cased
+        // parts.  Example:  "checkBox1_onChanged" or "_checkBox1_onChanged"
+        '^_?[a-z][a-z0-9]*([A-Z][a-z]?[a-z0-9]*)*_[a-z][a-z0-9]*([A-Z][a-z]?[a-z0-9]*)*$'
+      ]
+        .map((x) => `(${x})`)
+        .join('|'),
+      match: false
+    }
+  },
+
+  // Types should use PascalCase
+  {
+    // Group selector for: class, interface, typeAlias, enum, typeParameter
+    selectors: ['class', 'typeAlias', 'enum', 'typeParameter'],
+    format: ['PascalCase'],
+    leadingUnderscore: 'allow'
+  },
+
+  {
+    selectors: ['interface'],
+
+    // It is very common for a class to implement an interface of the same name.
+    // For example, the Widget class may implement the IWidget interface.  The "I" prefix
+    // avoids the need to invent a separate name such as "AbstractWidget" or "WidgetInterface".
+    // In TypeScript it is also common to declare interfaces that are implemented by primitive
+    // objects, here the "I" prefix also helps by avoiding spurious conflicts with classes
+    // by the same name.
+    format: ['PascalCase'],
+
+    custom: {
+      regex: '^_?I[A-Z]',
+      match: true
+    }
+  }
+];
+
+const commonConfig = [
+  // Manually authored .d.ts files are generally used to describe external APIs that are  not expected
+  // to follow our coding conventions.  Linting those files tends to produce a lot of spurious suppressions,
+  // so we simply ignore them.
+  globalIgnores(['**/*.d.ts']),
+
+  {
+    files: ['**/*.ts', '**/*.tsx'],
+    languageOptions: {
+      parser: typescriptEslintParser,
+      parserOptions: {
+        // The "project" path is resolved relative to parserOptions.tsconfigRootDir.
+        // Your local .eslintrc.js must specify that parserOptions.tsconfigRootDir=__dirname.
+        project: './tsconfig.json',
+
+        // Allow parsing of newer ECMAScript constructs used in TypeScript source code.  Although tsconfig.json
+        // may allow only a small subset of ES2018 features, this liberal setting ensures that ESLint will correctly
+        // parse whatever is encountered.
+        ecmaVersion: 2018,
+
+        sourceType: 'module'
+      }
+    },
+    plugins: {
+      '@rushstack': rushstackEslintPlugin,
+      '@rushstack/security': rushstackSecurityEslintPlugin,
+      '@typescript-eslint': typescriptEslintPlugin,
+      promise: promiseEslintPlugin
+    },
+    rules: {
+      // ====================================================================
+      // CUSTOM RULES
+      // ====================================================================
+
+      // RATIONALE:         See the @rushstack/eslint-plugin documentation
+      '@rushstack/no-new-null': 'warn',
+
+      // RATIONALE:         See the @rushstack/eslint-plugin documentation
+      '@rushstack/typedef-var': 'warn',
+
+      // RATIONALE:         See the @rushstack/eslint-plugin documentation
+      //                    This is enabled and classified as an error because it is required when using Heft.
+      //                    It's not required when using ts-jest, but still a good practice.
+      '@rushstack/hoist-jest-mock': 'error',
+
+      // ====================================================================
+      // SECURITY RULES
+      // ====================================================================
+
+      // RATIONALE:         This rule is used to prevent the use of insecure regular expressions, which can lead to
+      //                    security vulnerabilities such as ReDoS (Regular Expression Denial of Service).
+      '@rushstack/security/no-unsafe-regexp': 'warn',
+
+      // ====================================================================
+      // TYPESCRIPT RULES
+      // ====================================================================
+      // STANDARDIZED BY:   @typescript-eslint\eslint-plugin\dist\configs\recommended.json
+      '@typescript-eslint/adjacent-overload-signatures': 'warn',
+
+      // STANDARDIZED BY:   @typescript-eslint\eslint-plugin\dist\configs\recommended.json
+      '@typescript-eslint/no-unsafe-function-type': 'warn',
+
+      // STANDARDIZED BY:   @typescript-eslint\eslint-plugin\dist\configs\recommended.json
+      '@typescript-eslint/no-wrapper-object-types': 'warn',
+
+      // RATIONALE:         We require "x as number" instead of "<number>x" to avoid conflicts with JSX.
+      '@typescript-eslint/consistent-type-assertions': 'warn',
+
+      // RATIONALE:         We prefer "interface IBlah { x: number }" over "type Blah = { x: number }"
+      //                    because code is more readable when it is built from stereotypical forms
+      //                    (interfaces, enums, functions, etc.) instead of freeform type algebra.
+      '@typescript-eslint/consistent-type-definitions': 'warn',
+
+      // RATIONALE:         Code is more readable when the type of every variable is immediately obvious.
+      //                    Even if the compiler may be able to infer a type, this inference will be unavailable
+      //                    to a person who is reviewing a GitHub diff.  This rule makes writing code harder,
+      //                    but writing code is a much less important activity than reading it.
+      //
+      // STANDARDIZED BY:   @typescript-eslint\eslint-plugin\dist\configs\recommended.json
+      '@typescript-eslint/explicit-function-return-type': [
+        'warn',
+        {
+          allowExpressions: true,
+          allowTypedFunctionExpressions: true,
+          allowHigherOrderFunctions: false
+        }
+      ],
+
+      // STANDARDIZED BY:   @typescript-eslint\eslint-plugin\dist\configs\recommended.json
+      '@typescript-eslint/explicit-member-accessibility': 'warn',
+
+      // RATIONALE:         Object-oriented programming organizes code into "classes" that associate
+      //                    data structures (the class's fields) and the operations performed on those
+      //                    data structures (the class's members).  Studying the fields often reveals the "idea"
+      //                    behind a class.  The choice of which class a field belongs to may greatly impact
+      //                    the code readability and complexity.  Thus, we group the fields prominently at the top
+      //                    of the class declaration.  We do NOT enforce sorting based on public/protected/private
+      //                    or static/instance, because these designations tend to change as code evolves, and
+      //                    reordering methods produces spurious diffs that make PRs hard to read.  For classes
+      //                    with lots of methods, alphabetization is probably a more useful secondary ordering.
+      '@typescript-eslint/member-ordering': [
+        'warn',
+        {
+          default: 'never',
+          classes: ['field', 'constructor', 'method']
+        }
+      ],
+
+      // NOTE: This new rule replaces several deprecated rules from @typescript-eslint/eslint-plugin@2.3.3:
+      //
+      // - @typescript-eslint/camelcase
+      // - @typescript-eslint/class-name-casing
+      // - @typescript-eslint/interface-name-prefix
+      // - @typescript-eslint/member-naming
+      //
+      // Docs: https://github.com/typescript-eslint/typescript-eslint/blob/main/packages/eslint-plugin/docs/rules/naming-convention.md
+      '@typescript-eslint/naming-convention': [
+        'warn',
+        ...expandNamingConventionSelectors(commonNamingConventionSelectors)
+      ],
+
+      // STANDARDIZED BY:   @typescript-eslint\eslint-plugin\dist\configs\recommended.json
+      '@typescript-eslint/no-array-constructor': 'warn',
+
+      // STANDARDIZED BY:   @typescript-eslint\eslint-plugin\dist\configs\recommended.json
+      //
+      // RATIONALE:         The "any" keyword disables static type checking, the main benefit of using TypeScript.
+      //                    This rule should be suppressed only in very special cases such as JSON.stringify()
+      //                    where the type really can be anything.  Even if the type is flexible, another type
+      //                    may be more appropriate such as "unknown", "{}", or "Record<k,V>".
+      '@typescript-eslint/no-explicit-any': 'warn',
+
+      // RATIONALE:         The #1 rule of promises is that every promise chain must be terminated by a catch()
+      //                    handler.  Thus wherever a Promise arises, the code must either append a catch handler,
+      //                    or else return the object to a caller (who assumes this responsibility).  Unterminated
+      //                    promise chains are a serious issue.  Besides causing errors to be silently ignored,
+      //                    they can also cause a NodeJS process to terminate unexpectedly.
+      '@typescript-eslint/no-floating-promises': [
+        'error',
+        {
+          checkThenables: true
+        }
+      ],
+
+      // RATIONALE:         Catches a common coding mistake.
+      '@typescript-eslint/no-for-in-array': 'error',
+
+      // STANDARDIZED BY:   @typescript-eslint\eslint-plugin\dist\configs\recommended.json
+      '@typescript-eslint/no-misused-new': 'error',
+
+      // RATIONALE:         The "namespace" keyword is not recommended for organizing code because JavaScript lacks
+      //                    a "using" statement to traverse namespaces.  Nested namespaces prevent certain bundler
+      //                    optimizations.  If you are declaring loose functions/variables, it's better to make them
+      //                    static members of a class, since classes support property getters and their private
+      //                    members are accessible by unit tests.  Also, the exercise of choosing a meaningful
+      //                    class name tends to produce more discoverable APIs: for example, search+replacing
+      //                    the function "reverse()" is likely to return many false matches, whereas if we always
+      //                    write "Text.reverse()" is more unique.  For large scale organization, it's recommended
+      //                    to decompose your code into separate NPM packages, which ensures that component
+      //                    dependencies are tracked more conscientiously.
+      //
+      // STANDARDIZED BY:   @typescript-eslint\eslint-plugin\dist\configs\recommended.json
+      '@typescript-eslint/no-namespace': [
+        'warn',
+        {
+          // Discourage "namespace" in .ts and .tsx files
+          allowDeclarations: false,
+
+          // Allow it in .d.ts files that describe legacy libraries
+          allowDefinitionFiles: false
+        }
+      ],
+
+      // RATIONALE:         Parameter properties provide a shorthand such as "constructor(public title: string)"
+      //                    that avoids the effort of declaring "title" as a field.  This TypeScript feature makes
+      //                    code easier to write, but arguably sacrifices readability:  In the notes for
+      //                    "@typescript-eslint/member-ordering" we pointed out that fields are central to
+      //                    a class's design, so we wouldn't want to bury them in a constructor signature
+      //                    just to save some typing.
+      //
+      // STANDARDIZED BY:   @typescript-eslint\eslint-plugin\dist\configs\recommended.json
+      '@typescript-eslint/parameter-properties': 'warn',
+
+      // RATIONALE:         When left in shipping code, unused variables often indicate a mistake.  Dead code
+      //                    may impact performance.
+      //
+      // STANDARDIZED BY:   @typescript-eslint\eslint-plugin\dist\configs\recommended.json
+      '@typescript-eslint/no-unused-vars': [
+        'warn',
+        {
+          vars: 'all',
+          // Unused function arguments often indicate a mistake in JavaScript code.  However in TypeScript code,
+          // the compiler catches most of those mistakes, and unused arguments are fairly common for type signatures
+          // that are overriding a base class method or implementing an interface.
+          args: 'none',
+          // Unused error arguments are common and useful for inspection when a debugger is attached.
+          caughtErrors: 'none'
+        }
+      ],
+
+      // STANDARDIZED BY:   @typescript-eslint\eslint-plugin\dist\configs\recommended.json
+      '@typescript-eslint/no-use-before-define': [
+        'error',
+        {
+          // Base ESLint options
+
+          // We set functions=false so that functions can be ordered based on exported/local visibility
+          // similar to class methods.  Also the base lint rule incorrectly flags a legitimate case like:
+          //
+          //   function a(n: number): void {
+          //     if (n > 0) {
+          //       b(n-1); //   lint error
+          //     }
+          //   }
+          //   function b(n: number): void {
+          //     if (n > 0) {
+          //       a(n-1);
+          //     }
+          //   }
+          functions: false,
+          classes: true,
+          variables: true,
+
+          // TypeScript extensions
+
+          enums: true,
+          typedefs: true
+          // ignoreTypeReferences: true
+        }
+      ],
+
+      // TODO: This is a good rule for web browser apps, but it is commonly needed API for Node.js tools.
+      // '@typescript-eslint/no-var-requires': 'error',
+
+      // RATIONALE:         The "module" keyword is deprecated except when describing legacy libraries.
+      //
+      // STANDARDIZED BY:   @typescript-eslint\eslint-plugin\dist\configs\recommended.json
+      '@typescript-eslint/prefer-namespace-keyword': 'warn',
+
+      // RATIONALE:         We require explicit type annotations, even when the compiler could infer the type.
+      //                    This can be a controversial policy because it makes code more verbose.  There are
+      //                    a couple downsides to type inference, however.  First, it is not always available.
+      //                    For example, when reviewing a pull request or examining a Git history, we may see
+      //                    code like this:
+      //
+      //                        // What is the type of "y" here? The compiler knows, but the
+      //                        // person reading the code may have no clue.
+      //                        const x = f.();
+      //                        const y = x.z;
+      //
+      //                    Second, relying on implicit types also discourages design discussions and documentation.
+      //                    Consider this example:
+      //
+      //                        // Where's the documentation for "correlation" and "inventory"?
+      //                        // Where would you even write the TSDoc comments?
+      //                        function g() {
+      //                          return { correlation: 123, inventory: 'xyz' };
+      //                        }
+      //
+      //                    Implicit types make sense for small scale scenarios, where everyone is familiar with
+      //                    the project, and code should be "easy to write".  Explicit types are preferable
+      //                    for large scale scenarios, where people regularly work with source files they've never
+      //                    seen before, and code should be "easy to read."
+      //
+      // STANDARDIZED BY:   @typescript-eslint\eslint-plugin\dist\configs\recommended.json
+      '@typescript-eslint/typedef': [
+        'warn',
+        {
+          arrayDestructuring: false,
+          arrowParameter: false,
+          memberVariableDeclaration: true,
+          objectDestructuring: false,
+          parameter: true,
+          propertyDeclaration: true,
+
+          // This case is handled by our "@rushstack/typedef-var" rule
+          variableDeclaration: false,
+
+          // Normally we require type declarations for class members.  However, that rule is relaxed
+          // for situations where we need to bind the "this" pointer for a callback.  For example, consider
+          // this event handler for a React component:
+          //
+          //     class MyComponent {
+          //       public render(): React.ReactNode {
+          //          return (
+          //            <a href="#" onClick={this._onClick}> click me </a>
+          //          );
+          //        }
+          //
+          //        // The assignment here avoids the need for "this._onClick.bind(this)"
+          //        private _onClick = (event: React.MouseEvent<HTMLAnchorElement>): void => {
+          //          console.log("Clicked! " + this.props.title);
+          //        };
+          //      }
+          //
+          // This coding style has limitations and should be used sparingly.  For example, "_onClick"
+          // will not participate correctly in "virtual"/"override" inheritance.
+          //
+          // NOTE: This option affects both "memberVariableDeclaration" and "variableDeclaration" options.
+          variableDeclarationIgnoreFunction: true
+        }
+      ],
+
+      // ====================================================================
+      // RECOMMENDED RULES
+      // ====================================================================
+
+      // RATIONALE:         This rule warns if setters are defined without getters, which is probably a mistake.
+      'accessor-pairs': 'error',
+
+      // RATIONALE:         In TypeScript, if you write x["y"] instead of x.y, it disables type checking.
+      'dot-notation': [
+        'warn',
+        {
+          allowPattern: '^_'
+        }
+      ],
+
+      // RATIONALE:         Catches code that is likely to be incorrect
+      eqeqeq: 'error',
+
+      // STANDARDIZED BY:   eslint\conf\eslint-recommended.js
+      'for-direction': 'warn',
+
+      // RATIONALE:         Catches a common coding mistake.
+      'guard-for-in': 'error',
+
+      // RATIONALE:         If you have more than 2,000 lines in a single source file, it's probably time
+      //                    to split up your code.
+      'max-lines': ['warn', { max: 2000 }],
+
+      // STANDARDIZED BY:   eslint\conf\eslint-recommended.js
+      'no-async-promise-executor': 'error',
+
+      // RATIONALE:         "|" and "&" are relatively rare, and are more likely to appear as a mistake when
+      //                    someone meant "||" or "&&".  (But nobody types the other operators by mistake.)
+      'no-bitwise': [
+        'warn',
+        {
+          allow: [
+            '^',
+            // "|",
+            // "&",
+            '<<',
+            '>>',
+            '>>>',
+            '^=',
+            // "|=",
+            //"&=",
+            '<<=',
+            '>>=',
+            '>>>=',
+            '~'
+          ]
+        }
+      ],
+
+      // RATIONALE:         Deprecated language feature.
+      'no-caller': 'error',
+
+      // STANDARDIZED BY:   eslint\conf\eslint-recommended.js
+      'no-compare-neg-zero': 'error',
+
+      // STANDARDIZED BY:   eslint\conf\eslint-recommended.js
+      'no-cond-assign': 'error',
+
+      // STANDARDIZED BY:   eslint\conf\eslint-recommended.js
+      'no-constant-condition': 'warn',
+
+      // STANDARDIZED BY:   eslint\conf\eslint-recommended.js
+      'no-control-regex': 'error',
+
+      // STANDARDIZED BY:   eslint\conf\eslint-recommended.js
+      'no-debugger': 'warn',
+
+      // STANDARDIZED BY:   eslint\conf\eslint-recommended.js
+      'no-delete-var': 'error',
+
+      // RATIONALE:         Catches code that is likely to be incorrect
+      // STANDARDIZED BY:   eslint\conf\eslint-recommended.js
+      'no-duplicate-case': 'error',
+
+      // STANDARDIZED BY:   eslint\conf\eslint-recommended.js
+      'no-empty': 'warn',
+
+      // STANDARDIZED BY:   eslint\conf\eslint-recommended.js
+      'no-empty-character-class': 'error',
+
+      // STANDARDIZED BY:   eslint\conf\eslint-recommended.js
+      'no-empty-pattern': 'warn',
+
+      // RATIONALE:         Eval is a security concern and a performance concern.
+      'no-eval': 'warn',
+
+      // RATIONALE:         Catches code that is likely to be incorrect
+      // STANDARDIZED BY:   eslint\conf\eslint-recommended.js
+      'no-ex-assign': 'error',
+
+      // RATIONALE:         System types are global and should not be tampered with in a scalable code base.
+      //                    If two different libraries (or two versions of the same library) both try to modify
+      //                    a type, only one of them can win.  Polyfills are acceptable because they implement
+      //                    a standardized interoperable contract, but polyfills are generally coded in plain
+      //                    JavaScript.
+      'no-extend-native': 'error',
+
+      // STANDARDIZED BY:   eslint\conf\eslint-recommended.js
+      'no-extra-boolean-cast': 'warn',
+
+      'no-extra-label': 'warn',
+
+      // STANDARDIZED BY:   eslint\conf\eslint-recommended.js
+      'no-fallthrough': 'error',
+
+      // STANDARDIZED BY:   eslint\conf\eslint-recommended.js
+      'no-func-assign': 'warn',
+
+      // RATIONALE:         Catches a common coding mistake.
+      'no-implied-eval': 'error',
+
+      // STANDARDIZED BY:   eslint\conf\eslint-recommended.js
+      'no-invalid-regexp': 'error',
+
+      // RATIONALE:         Catches a common coding mistake.
+      'no-label-var': 'error',
+
+      // RATIONALE:         Eliminates redundant code.
+      'no-lone-blocks': 'warn',
+
+      // STANDARDIZED BY:   eslint\conf\eslint-recommended.js
+      'no-misleading-character-class': 'error',
+
+      // RATIONALE:         Catches a common coding mistake.
+      'no-multi-str': 'error',
+
+      // RATIONALE:         It's generally a bad practice to call "new Thing()" without assigning the result to
+      //                    a variable.  Either it's part of an awkward expression like "(new Thing()).doSomething()",
+      //                    or else implies that the constructor is doing nontrivial computations, which is often
+      //                    a poor class design.
+      'no-new': 'warn',
+
+      // RATIONALE:         Obsolete language feature that is deprecated.
+      'no-new-func': 'error',
+
+      // RATIONALE:         Obsolete language feature that is deprecated.
+      'no-new-object': 'error',
+
+      // RATIONALE:         Obsolete notation.
+      'no-new-wrappers': 'warn',
+
+      // RATIONALE:         Catches code that is likely to be incorrect
+      // STANDARDIZED BY:   eslint\conf\eslint-recommended.js
+      'no-octal': 'error',
+
+      // RATIONALE:         Catches code that is likely to be incorrect
+      'no-octal-escape': 'error',
+
+      // RATIONALE:         Catches code that is likely to be incorrect
+      // STANDARDIZED BY:   eslint\conf\eslint-recommended.js
+      'no-regex-spaces': 'error',
+
+      // RATIONALE:         Catches a common coding mistake.
+      'no-return-assign': 'error',
+
+      // RATIONALE:         Security risk.
+      'no-script-url': 'warn',
+
+      // STANDARDIZED BY:   eslint\conf\eslint-recommended.js
+      'no-self-assign': 'error',
+
+      // RATIONALE:         Catches a common coding mistake.
+      'no-self-compare': 'error',
+
+      // RATIONALE:         This avoids statements such as "while (a = next(), a && a.length);" that use
+      //                    commas to create compound expressions.  In general code is more readable if each
+      //                    step is split onto a separate line.  This also makes it easier to set breakpoints
+      //                    in the debugger.
+      'no-sequences': 'error',
+
+      // RATIONALE:         Catches code that is likely to be incorrect
+      // STANDARDIZED BY:   eslint\conf\eslint-recommended.js
+      'no-shadow-restricted-names': 'error',
+
+      // RATIONALE:         Obsolete language feature that is deprecated.
+      // STANDARDIZED BY:   eslint\conf\eslint-recommended.js
+      'no-sparse-arrays': 'error',
+
+      // RATIONALE:         Although in theory JavaScript allows any possible data type to be thrown as an exception,
+      //                    such flexibility adds pointless complexity, by requiring every catch block to test
+      //                    the type of the object that it receives.  Whereas if catch blocks can always assume
+      //                    that their object implements the "Error" contract, then the code is simpler, and
+      //                    we generally get useful additional information like a call stack.
+      'no-throw-literal': 'error',
+
+      // RATIONALE:         Catches a common coding mistake.
+      'no-unmodified-loop-condition': 'warn',
+
+      // STANDARDIZED BY:   eslint\conf\eslint-recommended.js
+      'no-unsafe-finally': 'error',
+
+      // RATIONALE:         Catches a common coding mistake.
+      'no-unused-expressions': 'warn',
+
+      // STANDARDIZED BY:   eslint\conf\eslint-recommended.js
+      'no-unused-labels': 'warn',
+
+      // STANDARDIZED BY:   eslint\conf\eslint-recommended.js
+      'no-useless-catch': 'warn',
+
+      // RATIONALE:         Avoids a potential performance problem.
+      'no-useless-concat': 'warn',
+
+      // RATIONALE:         The "var" keyword is deprecated because of its confusing "hoisting" behavior.
+      //                    Always use "let" or "const" instead.
+      //
+      // STANDARDIZED BY:   @typescript-eslint\eslint-plugin\dist\configs\recommended.json
+      'no-var': 'error',
+
+      // RATIONALE:         Generally not needed in modern code.
+      'no-void': 'error',
+
+      // RATIONALE:         Obsolete language feature that is deprecated.
+      // STANDARDIZED BY:   eslint\conf\eslint-recommended.js
+      'no-with': 'error',
+
+      // RATIONALE:         Makes logic easier to understand, since constants always have a known value
+      // @typescript-eslint\eslint-plugin\dist\configs\eslint-recommended.js
+      'prefer-const': 'warn',
+
+      // RATIONALE:         Catches a common coding mistake where "resolve" and "reject" are confused.
+      'promise/param-names': 'error',
+
+      // RATIONALE:         Catches code that is likely to be incorrect
+      // STANDARDIZED BY:   eslint\conf\eslint-recommended.js
+      'require-atomic-updates': 'error',
+
+      // STANDARDIZED BY:   eslint\conf\eslint-recommended.js
+      'require-yield': 'warn',
+
+      // "Use strict" is redundant when using the TypeScript compiler.
+      strict: ['error', 'never'],
+
+      // RATIONALE:         Catches code that is likely to be incorrect
+      // STANDARDIZED BY:   eslint\conf\eslint-recommended.js
+      'use-isnan': 'error'
+
+      // The "no-restricted-syntax" rule is a general purpose pattern matcher that we can use to experiment with
+      // new rules.  If a rule works well, we should convert it to a proper rule so it gets its own name
+      // for suppressions and documentation.
+      // How it works:    https://eslint.org/docs/rules/no-restricted-syntax
+      // AST visualizer:  https://astexplorer.net/
+      // Debugger:        http://estools.github.io/esquery/
+      //
+      // "no-restricted-syntax": [
+      // ],
+    }
+  },
+
+  // ====================================================================
+  // TESTING RULES
+  // ====================================================================
+  {
+    files: [
+      // Test files
+      '**/*.test.ts',
+      '**/*.test.tsx',
+      '**/*.spec.ts',
+      '**/*.spec.tsx',
+
+      // Facebook convention
+      '**/__mocks__/*.ts',
+      '**/__mocks__/*.tsx',
+      '**/__tests__/*.ts',
+      '**/__tests__/*.tsx',
+
+      // Microsoft convention
+      '**/test/*.ts',
+      '**/test/*.tsx'
+    ],
+    rules: {
+      // Unit tests sometimes use a standalone statement like "new Thing(123);" to test a constructor.
+      'no-new': 'off',
+
+      // Jest's mocking API is designed in a way that produces compositional data types that often have
+      // no concise description.  Since test code does not ship, and typically does not introduce new
+      // concepts or algorithms, the usual arguments for prioritizing readability over writability can be
+      // relaxed in this case.
+      '@rushstack/typedef-var': 'off'
+    }
+  }
+];
+
+module.exports = { commonNamingConventionSelectors, commonConfig };

package/flat/profile/_macros.js

@@ -0,0 +1,104 @@
+// Copyright (c) Microsoft Corporation. All rights reserved. Licensed under the MIT license.
+// See LICENSE in the project root for license information.
+
+// This is a workaround for the @typescript-eslint/naming-convention rule, whose options currently
+// support a "selector" field that cannot match multiple selectors. This function receives an input
+// array such as:
+//
+// [
+//   {
+//     selectors: ['class', 'typeAlias', 'enum'],
+//     format: ['PascalCase']
+//   },
+//   . . .
+// ]
+//
+// ...and transforms "selectors" -> "selector, returning an array with expanded entries like this:
+//
+// [
+//   {
+//     selector: 'class',
+//     format: ['PascalCase']
+//   },
+//   {
+//     selector: 'typeAlias',
+//     format: ['PascalCase']
+//   },
+//   {
+//     selector: 'enum',
+//     format: ['PascalCase']
+//   },
+//   . . .
+// ]
+//
+// It also supports a "enforceLeadingUnderscoreWhenPrivate" macro that expands this:
+//
+// [
+//   {
+//     selectors: ['property'],
+//     enforceLeadingUnderscoreWhenPrivate: true,
+//     format: ['camelCase']
+//   },
+//   . . .
+// ]
+//
+// ...to produce this:
+//
+// [
+//   {
+//     selector: 'property',
+//
+//     leadingUnderscore: 'allow',
+//     format: ['camelCase']
+//   },
+//   {
+//     selector: 'property',
+//     modifiers: ['private'],
+//
+//     leadingUnderscore: 'require',
+//     format: ['camelCase']
+//   },
+//   . . .
+// ]
+function expandNamingConventionSelectors(inputBlocks) {
+  const firstPassBlocks = [];
+
+  // Expand "selectors" --> "selector"
+  for (const block of inputBlocks) {
+    for (const selector of block.selectors) {
+      const expandedBlock = { ...block };
+      delete expandedBlock.selectors;
+      expandedBlock.selector = selector;
+      firstPassBlocks.push(expandedBlock);
+    }
+  }
+
+  // Expand "enforceLeadingUnderscoreWhenPrivate" --> "leadingUnderscore"
+  const secondPassBlocks = [];
+  for (const block of firstPassBlocks) {
+    if (block.enforceLeadingUnderscoreWhenPrivate) {
+      const expandedBlock1 = {
+        ...block,
+        leadingUnderscore: 'allow'
+      };
+      delete expandedBlock1.enforceLeadingUnderscoreWhenPrivate;
+      secondPassBlocks.push(expandedBlock1);
+
+      const expandedBlock2 = {
+        ...block,
+        modifiers: [...(block.modifiers ?? []), 'private'],
+        leadingUnderscore: 'require'
+      };
+      delete expandedBlock2.enforceLeadingUnderscoreWhenPrivate;
+      secondPassBlocks.push(expandedBlock2);
+    } else {
+      secondPassBlocks.push(block);
+    }
+  }
+
+  return secondPassBlocks;
+}
+
+module.exports = {
+  expandNamingConventionSelectors: expandNamingConventionSelectors
+};

package/flat/profile/node-trusted-tool.js

@@ -0,0 +1,26 @@
+// Copyright (c) Microsoft Corporation. All rights reserved. Licensed under the MIT license.
+// See LICENSE in the project root for license information.
+
+// This profile enables lint rules intended for a Node.js project whose inputs will always
+// come from a developer or other trusted source.  Most build system tasks are like this,
+// since they operate on exclusively files prepared by a developer.
+//
+// This profile disables certain security rules that would otherwise prohibit APIs that could
+// cause a denial-of-service by consuming too many resources, or which might interact with
+// the filesystem in unsafe ways.  Such activities are safe and commonplace for a trusted tool.
+//
+// DO NOT use this profile for a library project that might also be loaded by a Node.js service;
+// use "@rushstack/eslint-config/profiles/node" instead.
+
+const { commonConfig } = require('./_common');
+
+module.exports = [
+  ...commonConfig,
+  {
+    files: ['**/*.ts', '**/*.tsx'],
+    rules: {
+      // This is disabled for trusted tools because the tool is known to be safe.
+      '@rushstack/security/no-unsafe-regexp': 'off'
+    }
+  }
+];

package/flat/profile/node.js

@@ -0,0 +1,10 @@
+// Copyright (c) Microsoft Corporation. All rights reserved. Licensed under the MIT license.
+// See LICENSE in the project root for license information.
+
+// This profile enables lint rules intended for a general Node.js project, typically a web service.
+// It enables security rules that assume the service could receive malicious inputs from an
+// untrusted user.  If that is not the case, consider using the "node-trusted-tool" profile instead.
+
+const { commonConfig } = require('./_common');
+
+module.exports = [...commonConfig];

package/flat/profile/web-app.js

@@ -0,0 +1,12 @@
+// Copyright (c) Microsoft Corporation. All rights reserved. Licensed under the MIT license.
+// See LICENSE in the project root for license information.
+
+// This profile enables lint rules intended for a web application.  It enables security rules
+// that are relevant to web browser APIs such as DOM.
+//
+// Also use this profile if you are creating a library that can be consumed by both Node.js
+// and web applications.
+
+const { commonConfig } = require('./_common');
+
+module.exports = [...commonConfig];

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@rushstack/eslint-config",
-  "version": "4.2.0",
+  "version": "4.4.0",
   "description": "A TypeScript ESLint ruleset designed for large teams and projects",
   "license": "MIT",
   "repository": {
@@ -19,25 +19,25 @@
     "typescript"
   ],
   "peerDependencies": {
-    "eslint": "^8.57.0",
+    "eslint": "^8.57.0 || ^9.25.1",
     "typescript": ">=4.7.0"
   },
   "dependencies": {
-    "@typescript-eslint/eslint-plugin": "~8.24.0",
-    "@typescript-eslint/utils": "~8.24.0",
-    "@typescript-eslint/parser": "~8.24.0",
-    "@typescript-eslint/typescript-estree": "~8.24.0",
-    "eslint-plugin-promise": "~6.1.1",
-    "eslint-plugin-react": "~7.33.2",
+    "@typescript-eslint/eslint-plugin": "~8.31.0",
+    "@typescript-eslint/utils": "~8.31.0",
+    "@typescript-eslint/parser": "~8.31.0",
+    "@typescript-eslint/typescript-estree": "~8.31.0",
+    "eslint-plugin-promise": "~7.2.1",
+    "eslint-plugin-react": "~7.37.5",
     "eslint-plugin-tsdoc": "~0.4.0",
-    "@rushstack/eslint-patch": "1.10.5",
-    "@rushstack/eslint-plugin": "0.17.0",
-    "@rushstack/eslint-plugin-security": "0.9.0",
-    "@rushstack/eslint-plugin-packlets": "0.10.0"
+    "@rushstack/eslint-patch": "1.12.0",
+    "@rushstack/eslint-plugin-packlets": "0.12.0",
+    "@rushstack/eslint-plugin-security": "0.11.0",
+    "@rushstack/eslint-plugin": "0.19.0"
   },
   "devDependencies": {
-    "eslint": "~8.57.0",
-    "typescript": "~5.7.3"
+    "eslint": "~9.25.1",
+    "typescript": "~5.8.2"
   },
   "scripts": {
     "build": "",

package/profile/_common.js

@@ -337,7 +337,12 @@ function buildRules(profile) {
           //                    or else return the object to a caller (who assumes this responsibility).  Unterminated
           //                    promise chains are a serious issue.  Besides causing errors to be silently ignored,
           //                    they can also cause a NodeJS process to terminate unexpectedly.
-          '@typescript-eslint/no-floating-promises': 'error',
+          '@typescript-eslint/no-floating-promises': [
+            'error',
+            {
+              checkThenables: true
+            }
+          ],
 
           // RATIONALE:         Catches a common coding mistake.
           '@typescript-eslint/no-for-in-array': 'error',