no-empty-function
Disallow empty functions.
Extending "plugin:@typescript-eslint/stylistic"
in an ESLint configuration enables this rule.
This rule extends the base eslint/no-empty-function
rule.
It adds support for handling TypeScript specific code that would otherwise trigger the rule.
One example of valid TypeScript specific code that would otherwise trigger the no-empty-function
rule is the use of parameter properties in constructor functions.
How to Use
module.exports = {
"rules": {
// Note: you must disable the base rule as it can report incorrect errors
"no-empty-function": "off",
"@typescript-eslint/no-empty-function": "error"
}
};
Try this rule in the playground ↗
Options
See eslint/no-empty-function
options.
This rule adds the following options:
type AdditionalAllowOptionEntries =
| 'private-constructors'
| 'protected-constructors'
| 'decoratedFunctions'
| 'overrideMethods';
type AllowOptionEntries =
| BaseNoEmptyFunctionAllowOptionEntries
| AdditionalAllowOptionEntries;
interface Options extends BaseNoEmptyFunctionOptions {
allow?: Array<AllowOptionEntries>;
}
const defaultOptions: Options = {
...baseNoEmptyFunctionDefaultOptions,
allow: [],
};
allow: private-constructors
Examples of correct code for the { "allow": ["private-constructors"] }
option:
class Foo {
private constructor() {}
}
Open in Playgroundallow: protected-constructors
Examples of correct code for the { "allow": ["protected-constructors"] }
option:
class Foo {
protected constructor() {}
}
Open in Playgroundallow: decoratedFunctions
Examples of correct code for the { "allow": ["decoratedFunctions"] }
option:
class Foo {
@decorator()
foo() {}
}
Open in Playgroundallow: overrideMethods
Examples of correct code for the { "allow": ["overrideMethods"] }
option:
abstract class Base {
protected greet(): void {
console.log('Hello!');
}
}
class Foo extends Base {
protected override greet(): void {}
}
Open in PlaygroundWhen Not To Use It
If you are working with external APIs that require functions even if they do nothing, then you may want to avoid this rule. You might consider using ESLint disable comments for those specific situations instead of completely disabling this rule.
Test code often violates this rule as well.
If your testing setup doesn't support "mock" or "spy" functions such as jest.fn()
, sinon.spy()
, or vi.fn()
, you may wish to disable this rule in test files.
Again, if those cases aren't extremely common, you might consider using ESLint disable comments for those specific situations instead of completely disabling this rule in test files.