Skip to main content

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

.eslintrc.cjs
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 Playground

allow: protected-constructors

Examples of correct code for the { "allow": ["protected-constructors"] } option:

class Foo {
protected constructor() {}
}
Open in Playground

allow: decoratedFunctions

Examples of correct code for the { "allow": ["decoratedFunctions"] } option:

class Foo {
@decorator()
foo() {}
}
Open in Playground

allow: 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 Playground

When 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.

Resources

Taken with ❤️ from ESLint core.