no-extraneous-class
Disallow classes used as namespaces.
在 ESLint 配置 中扩展"plugin:@typescript-eslint/strict" 可启用此规则。
此规则报告类何时没有非静态成员，例如专门用作静态命名空间的类。
¥This rule reports when a class has no non-static members, such as for a class used exclusively as a static namespace.
来自 OOP 范式的用户可以将其实用函数封装在一个额外的类中，而不是将它们放在 ECMAScript 模块的顶层。在 JavaScript 和 TypeScript 项目中通常不需要这样做。
¥Users who come from a OOP paradigm may wrap their utility functions in an extra class, instead of putting them at the top level of an ECMAScript module. Doing so is generally unnecessary in JavaScript and TypeScript projects.
-
封装类在不添加任何结构改进的情况下为代码增加了额外的认知复杂性
¥Wrapper classes add extra cognitive complexity to code without adding any structural improvements
-
无论要放在它们上面的是什么，例如效用函数，都已经通过模块进行了组织。
¥Whatever would be put on them, such as utility functions, are already organized by virtue of being in a module.
-
或者，你可以
import * as ...模块以将它们全部放在单个对象中。¥As an alternative, you can
import * as ...the module to get all of them in a single object.
-
-
当你开始输入属性名称时，IDE 无法为静态类或命名空间导入的属性提供良好的建议
¥IDEs can't provide as good suggestions for static class or namespace imported properties when you start typing property names
-
当所有未使用的变量等都在类中时，静态分析代码会更加困难（参见：在 TypeScript 中查找死代码（和死类型））。
¥It's more difficult to statically analyze code for unused variables, etc. when they're all on the class (see: Finding dead code (and dead types) in TypeScript).
此规则还报告仅具有构造函数而没有字段的类。这些类通常可以用独立的函数替换。
¥This rule also reports classes that have only a constructor and no fields. Those classes can generally be replaced with a standalone function.
- Flat Config
- Legacy Config
export default tseslint.config({
rules: {
"@typescript-eslint/no-extraneous-class": "error"
}
});
module.exports = {
"rules": {
"@typescript-eslint/no-extraneous-class": "error"
}
};
在线运行试试这个规则 ↗
示例
¥Examples
- ❌ Incorrect
- ✅ Correct
class StaticConstants {
static readonly version = 42;
static isProduction() {
return process.env.NODE_ENV === 'production';
}
}
class HelloWorldLogger {
constructor() {
console.log('Hello, world!');
}
}
abstract class Foo {}
export const version = 42;
export function isProduction() {
return process.env.NODE_ENV === 'production';
}
function logHelloWorld() {
console.log('Hello, world!');
}
abstract class Foo {
abstract prop: string;
}
备择方案
¥Alternatives
单独导出（推荐）
¥Individual Exports (Recommended)
我们建议你从模块中单独导出实用程序，而不是使用静态实用程序类。
¥Instead of using a static utility class we recommend you individually export the utilities from your module.
- ❌ Incorrect
- ✅ Correct
export class Utilities {
static util1() {
return Utilities.util3();
}
static util2() {
/* ... */
}
static util3() {
/* ... */
}
}
export function util1() {
return util3();
}
export function util2() {
/* ... */
}
export function util3() {
/* ... */
}
命名空间导入（不推荐）
¥Namespace Imports (Not Recommended)
如果你强烈希望将模块中的所有构造用作单个对象的属性，则可以对模块进行 import * as 处理。这被称为 "命名空间导入"。命名空间导入有时更可取，因为它们保留所有属性的嵌套，并且在你开始或停止使用模块中的各种属性时不需要更改。
¥If you strongly prefer to have all constructs from a module available as properties of a single object, you can import * as the module.
This is known as a "namespace import".
Namespace imports are sometimes preferable because they keep all properties nested and don't need to be changed as you start or stop using various properties from the module.
然而，命名空间导入受到以下缺点的影响：
¥However, namespace imports are impacted by these downsides:
-
在现代打包器中，它们也不能很好地处理树摇动
¥They also don't play as well with tree shaking in modern bundlers
-
它们在使用每个属性之前需要名称前缀
¥They require a name prefix before each property's usage
- ❌ Incorrect
- ⚠️ Namespace Imports
- ✅ Standalone Imports
// utilities.ts
export class Utilities {
static sayHello() {
console.log('Hello, world!');
}
}
// consumers.ts
import { Utilities } from './utilities';
Utilities.sayHello();
// utilities.ts
export function sayHello() {
console.log('Hello, world!');
}
// consumers.ts
import * as utilities from './utilities';
utilities.sayHello();
// utilities.ts
export function sayHello() {
console.log('Hello, world!');
}
// consumers.ts
import { sayHello } from './utilities';
sayHello();
关于修改变量的注释
¥Notes on Mutating Variables
你需要注意的一种情况是导出可变变量。虽然类属性可以从外部改变，但导出的变量始终是常量。这意味着导入器只能读取为其分配的第一个值，而无法写入变量。
¥One case you need to be careful of is exporting mutable variables. While class properties can be mutated externally, exported variables are always constant. This means that importers can only ever read the first value they are assigned and cannot write to the variables.
需要写入导出变量的情况非常罕见，通常被认为是代码异味。如果你确实需要它，你可以使用 getter 和 setter 函数来完成它：
¥Needing to write to an exported variable is very rare and is generally considered a code smell. If you do need it you can accomplish it using getter and setter functions:
- ❌ Incorrect
- ✅ Correct
export class Utilities {
static mutableCount = 1;
static incrementCount() {
Utilities.mutableCount += 1;
}
}
let mutableCount = 1;
export function getMutableCount() {
return mutableField;
}
export function incrementCount() {
mutableField += 1;
}
选项
该规则接受以下选项:
type Options = [
{
/** Whether to allow extraneous classes that contain only a constructor. */
allowConstructorOnly?: boolean;
/** Whether to allow extraneous classes that have no body (i.e. are empty). */
allowEmpty?: boolean;
/** Whether to allow extraneous classes that only contain static members. */
allowStaticOnly?: boolean;
/** Whether to allow extraneous classes that include a decorator. */
allowWithDecorator?: boolean;
},
];
const defaultOptions: Options = [
{
allowConstructorOnly: false,
allowEmpty: false,
allowStaticOnly: false,
allowWithDecorator: false,
},
];
¥Options
此规则仅检查常量文字值（字符串、模板字符串、数字、bigint、布尔值、正则表达式、null）。该规则的每个选项都为特定类型的类添加了豁免。
¥This rule normally bans classes that are empty (have no constructor or fields). The rule's options each add an exemption for a specific type of class.
allowConstructorOnly
Whether to allow extraneous classes that contain only a constructor. Default: false.
- ❌ Incorrect
- ✅ Correct
class NoFields {}
class NoFields {
constructor() {
console.log('Hello, world!');
}
}
allowEmpty
Whether to allow extraneous classes that have no body (i.e. are empty). Default: false.
- ❌ Incorrect
- ✅ Correct
class NoFields {
constructor() {
console.log('Hello, world!');
}
}
class NoFields {}
allowStaticOnly
Whether to allow extraneous classes that only contain static members. Default: false.
我们强烈建议不要使用 allowStaticOnly 豁免。它违背了该规则的主要目的，即阻止仅用于静态成员的类。
¥We strongly recommend against the allowStaticOnly exemption.
It works against this rule's primary purpose of discouraging classes used only for static members.
- ❌ Incorrect
- ✅ Correct
class EmptyClass {}
class NotEmptyClass {
static version = 42;
}
allowWithDecorator
Whether to allow extraneous classes that include a decorator. Default: false.
- ❌ Incorrect
- ✅ Correct
class Constants {
static readonly version = 42;
}
@logOnRead()
class Constants {
static readonly version = 42;
}
何时不使用它
¥When Not To Use It
如果你的项目是在现代类和命名空间实践之前设置的，并且你没有时间进行切换，那么你实际上可能无法使用此规则。你可以考虑在这些特定情况下使用 ESLint 禁用注释，而不是完全禁用此规则。
¥If your project was set up before modern class and namespace practices, and you don't have the time to switch over, you might not be practically able to use this rule. You might consider using ESLint disable comments for those specific situations instead of completely disabling this rule.
'## 资源'