@typescript-eslint/eslint-plugin 8.21.1-alpha.1 → 8.21.1-alpha.11

package/docs/rules/no-require-imports.mdx

@@ -9,7 +9,9 @@ import TabItem from '@theme/TabItem';
 >
 > See **https://typescript-eslint.io/rules/no-require-imports** for documentation.
 
-Prefer the newer ES6-style imports over `require()`.
+Depending on your TSConfig settings and whether you're authoring ES Modules or CommonJS, TS may allow both `import` and `require()` to be used, even within a single file.
+
+This rule enforces that you use the newer ES Module `import` syntax over CommonJS `require()`.
 
 ## Examples
 
@@ -42,7 +44,7 @@ import * as lib3 from 'lib3';
 
 These strings will be compiled into regular expressions with the `u` flag and be used to test against the imported path. A common use case is to allow importing `package.json`. This is because `package.json` commonly lives outside of the TS root directory, so statically importing it would lead to root directory conflicts, especially with `resolveJsonModule` enabled. You can also use it to allow importing any JSON if your environment doesn't support JSON modules, or use it for other cases where `import` statements cannot work.
 
-With `{allow: ['/package\\.json$']}`:
+With `{ allow: ['/package\\.json$'] }`:
 
 <Tabs>
 <TabItem value="❌ Incorrect">
@@ -66,9 +68,9 @@ console.log(require('../package.json').version);
 {/* insert option description */}
 
 When set to `true`, `import ... = require(...)` declarations won't be reported.
-This is useful if you use certain module options that require strict CommonJS interop semantics.
+This is beneficial if you use certain module options that require strict CommonJS interop semantics, such as [verbatimModuleSyntax](https://www.typescriptlang.org/tsconfig/#verbatimModuleSyntax).
 
-With `{allowAsImport: true}`:
+With `{ allowAsImport: true }`:
 
 <Tabs>
 <TabItem value="❌ Incorrect">
@@ -90,10 +92,22 @@ import foo from 'foo';
 </TabItem>
 </Tabs>
 
+## Usage with CommonJS
+
+While this rule is primarily intended to promote ES Module syntax, it still makes sense to enable this rule when authoring CommonJS modules.
+
+If you prefer to use TypeScript's built-in `import ... from ...` ES Module syntax, which is transformed to `require()` calls during transpilation when outputting CommonJS, you can use the rule's default behavior.
+
+If, instead, you prefer to use `require()` syntax, we recommend you use this rule with [`allowAsImport`](#allowAsImport) enabled.
+That way, you still enforce usage of `import ... = require(...)` rather than bare `require()` calls, which are not statically analyzed by TypeScript.
+We don't directly a way to _prohibit_ ES Module syntax from being used; consider instead using TypeScript's [`verbatimModuleSyntax`](https://www.typescriptlang.org/tsconfig/#verbatimModuleSyntax) option if you find yourself in a situation where you would want this.
+
 ## When Not To Use It
 
-If your project frequently uses older CommonJS `require`s, then this rule might not be applicable to you.
-If only a subset of your project uses `require`s then you might consider using [ESLint disable comments](https://eslint.org/docs/latest/use/configure/rules#using-configuration-comments-1) for those specific situations instead of completely disabling this rule.
+If you are authoring CommonJS modules _and_ your project frequently uses dynamic `require`s, then this rule might not be applicable to you.
+Otherwise the `allowAsImport` option probably suits your needs.
+
+If only a subset of your project uses dynamic `require`s then you might consider using [ESLint disable comments](https://eslint.org/docs/latest/use/configure/rules#using-configuration-comments-1) for those specific situations instead of completely disabling this rule.
 
 ## Related To
 

package/docs/rules/no-unnecessary-template-expression.mdx

@@ -28,6 +28,8 @@ The new name is a drop-in replacement with identical functionality.
 
 const ab1 = `${'a'}${'b'}`;
 const ab2 = `a${'b'}`;
+type AB1 = `${'A'}${'B'}`;
+type AB2 = `A${'B'}`;
 
 const stringWithNumber = `${'1 + 1 = '}${2}`;
 
@@ -38,9 +40,13 @@ const stringWithBoolean = `${'true is '}${true}`;
 
 const text = 'a';
 const wrappedText = `${text}`;
+type Text = 'A';
+type WrappedText = `${Text}`;
 
 declare const intersectionWithString: string & { _brand: 'test-brand' };
 const wrappedIntersection = `${intersectionWithString}`;
+type IntersectionWithString = string & { _brand: 'test-brand' };
+type WrappedIntersection = `${IntersectionWithString}`;
 ```
 
 </TabItem>
@@ -51,6 +57,15 @@ const wrappedIntersection = `${intersectionWithString}`;
 
 const ab1 = `ab`;
 const ab2 = `ab`;
+type AB = `AB`;
+
+// Transforming enum members into string unions using template literals is allowed.
+enum ABC {
+  A = 'A',
+  B = 'B',
+  C = 'C',
+}
+type ABCUnion = `${ABC}`;
 
 const stringWithNumber = `1 + 1 = 2`;
 
@@ -61,9 +76,13 @@ const stringWithBoolean = `true is true`;
 
 const text = 'a';
 const wrappedText = text;
+type Text = 'A';
+type WrappedText = Text;
 
 declare const intersectionWithString: string & { _brand: 'test-brand' };
 const wrappedIntersection = intersectionWithString;
+type IntersectionWithString = string & { _brand: 'test-brand' };
+type WrappedIntersection = IntersectionWithString;
 ```
 
 </TabItem>

package/docs/rules/no-unused-vars.mdx

@@ -12,7 +12,11 @@ import TabItem from '@theme/TabItem';
 This rule extends the base [`eslint/no-unused-vars`](https://eslint.org/docs/rules/no-unused-vars) rule.
 It adds support for TypeScript features, such as types.
 
-## Benefits Over TypeScript
+## Options
+
+## FAQs
+
+### What benefits does this rule have over TypeScript?
 
 TypeScript provides [`noUnusedLocals`](https://www.typescriptlang.org/tsconfig#noUnusedLocals) and [`noUnusedParameters`](https://www.typescriptlang.org/tsconfig#noUnusedParameters) compiler options that can report errors on unused local variables or parameters, respectively.
 Those compiler options can be convenient to use if you don't want to set up ESLint and typescript-eslint.
@@ -52,3 +56,66 @@ Also see similar rules provided by ESLint:
 
 - [`no-unused-private-class-members`](https://eslint.org/docs/latest/rules/no-unused-private-class-members)
 - [`no-unused-labels`](https://eslint.org/docs/latest/rules/no-unused-labels)
+
+### Why does this rule report variables used only for types?
+
+This rule does not count type-only uses when determining whether a variable is used.
+Declaring variables only to use them for types adds code and runtime complexity.
+The variables are never actually used at runtime.
+They can be misleading to readers of the code.
+
+<Tabs>
+
+<TabItem value="typeof Variables">
+
+For example, if a variable is only used for `typeof`, this rule will report:
+
+```ts
+const box = {
+  //  ~~~
+  //  'box' is assigned a value but only used as a type.
+  value: 123,
+};
+
+export type Box = typeof box;
+```
+
+Instead, it's often cleaner and less code to write out the types directly:
+
+```ts
+export interface Box {
+  value: number;
+}
+```
+
+</TabItem>
+
+<TabItem value="Zod Schemas">
+
+For example, if a Zod schema variable is only used for `typeof`, this rule will report:
+
+```ts
+import { z } from 'zod';
+
+const schema = z.object({
+  //  ~~~~~~
+  //  'schema' is assigned a value but only used as a type.
+  value: z.number(),
+});
+
+export type Box = z.infer<typeof schema>;
+```
+
+Instead, it's often cleaner and less code to write out the types directly:
+
+```ts
+export interface Box {
+  value: number;
+}
+```
+
+</TabItem>
+
+</Tabs>
+
+If you find yourself writing runtime values only for types, consider refactoring your code to declare types directly.

package/docs/rules/prefer-nullish-coalescing.mdx

@@ -16,6 +16,7 @@ This rule reports when you may consider replacing:
 
 - An `||` operator with `??`
 - An `||=` operator with `??=`
+- Ternary expressions (`?:`) that are equivalent to `||` or `??` with `??`
 
 :::caution
 This rule will not work as expected if [`strictNullChecks`](https://www.typescriptlang.org/tsconfig#strictNullChecks) is not enabled.
@@ -42,7 +43,9 @@ foo === undefined ? 'a string' : foo;
 
 const foo: string | null = 'bar';
 foo !== null ? foo : 'a string';
+foo ? foo : 'a string';
 foo === null ? 'a string' : foo;
+!foo ? 'a string' : foo;
 ```
 
 Correct code for `ignoreTernaryTests: false`:
@@ -61,6 +64,8 @@ foo ?? 'a string';
 const foo: string | null = 'bar';
 foo ?? 'a string';
 foo ?? 'a string';
+foo ?? 'a string';
+foo ?? 'a string';
 ```
 
 ### `ignoreConditionalTests`

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@typescript-eslint/eslint-plugin",
-  "version": "8.21.1-alpha.1",
+  "version": "8.21.1-alpha.11",
   "description": "TypeScript plugin for ESLint",
   "files": [
     "dist",
@@ -61,10 +61,10 @@
   },
   "dependencies": {
     "@eslint-community/regexpp": "^4.10.0",
-    "@typescript-eslint/scope-manager": "8.21.1-alpha.1",
-    "@typescript-eslint/type-utils": "8.21.1-alpha.1",
-    "@typescript-eslint/utils": "8.21.1-alpha.1",
-    "@typescript-eslint/visitor-keys": "8.21.1-alpha.1",
+    "@typescript-eslint/scope-manager": "8.21.1-alpha.11",
+    "@typescript-eslint/type-utils": "8.21.1-alpha.11",
+    "@typescript-eslint/utils": "8.21.1-alpha.11",
+    "@typescript-eslint/visitor-keys": "8.21.1-alpha.11",
     "graphemer": "^1.4.0",
     "ignore": "^5.3.1",
     "natural-compare": "^1.4.0",
@@ -75,8 +75,8 @@
     "@types/marked": "^5.0.2",
     "@types/mdast": "^4.0.3",
     "@types/natural-compare": "*",
-    "@typescript-eslint/rule-schema-to-typescript-types": "8.21.1-alpha.1",
-    "@typescript-eslint/rule-tester": "8.21.1-alpha.1",
+    "@typescript-eslint/rule-schema-to-typescript-types": "8.21.1-alpha.11",
+    "@typescript-eslint/rule-tester": "8.21.1-alpha.11",
     "ajv": "^6.12.6",
     "cross-env": "^7.0.3",
     "cross-fetch": "*",