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's 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.