useConsistentMethodSignatures

TypeScript and TSX

Caution

This rule is part of the nursery group. This means that it is experimental and the behavior can change at any time.

Summary

• Rule available since: v2.3.14
• Diagnostic Category: lint/nursery/useConsistentMethodSignatures
• This rule doesn’t have a fix.
• The default severity of this rule is information.
• Sources:
  • Same as @typescript-eslint/method-signature-style

How to configure

biome.json

{
  "linter": {
    "rules": {
      "nursery": {
        "useConsistentMethodSignatures": "error"
      }
    }
  }
}

Description

Enforce consistent use of either method signatures or function properties within interfaces and type aliases.

TypeScript provides 2 different ways to declare methods within interfaces and object types:

interface Example {
  // method shorthand syntax
  methodFunc(arg: string): void;

  // regular property with function type
  prop: (arg: string) => void;
}

// These forms correspond to the analogous JS object literal patterns:
const obj = {
  methodFunc(arg) {},
  prop: (arg) => {},
} satisfies Example;

While mostly a matter of stylistic consistency, the two gain subtle differences in behavior when the strictFunctionTypes compiler option is enabled.
More specifically, its stricter contravariant checks will only apply to functions written in property syntax — ones written as methods will remain with the weaker bivariant type checks.

What’s the difference?

To illustrate the differences between method bivariance and contravariance, consider the following snippet of code:

interface Emitter {
  methodFunc(arg: Event): void;
  propFunc: (arg: Event) => void;
}

interface SpecialEvent extends Event {
  isBirthday: boolean;
}

interface SpecialEmitter extends Emitter {
  methodFunc(arg: SpecialEvent): void; // OK
  propFunc: (arg: SpecialEvent) => void; // Error under `strictFunctionTypes`
}

In the above example, SpecialEmitter.methodFunc is compatible with Emitter.methodFunc under bivariant¹ checks, as SpecialEvent is assignable to Event (i.e. all SpecialEvents are guaranteed to be valid Events).
On the other hand, the strict contravariant checks for function properties produce errors on propFunc as the reverse is not guaranteed — Event is not assignable to SpecialEvent (i.e. not all Events are guaranteed to be valid SpecialEvents).

The full rationale for this behavior can be found in the TypeScript handbook.

To avoid inconsistent type assignability issues and enforce stylistic consistency, this rule attempts to ensure either method- or property-style declarations are used consistently across a given codebase.

Without strictFunctionTypes enabled, method signatures and function properties become functionally identical. In this case, which option to use simply becomes a matter of personal preference.

Examples

Invalid

interface Example {
  methodFunc(arg: string): number;
}

code-block.ts:2:3 lint/nursery/useConsistentMethodSignatures ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

  ℹ Prefer using property-style over method-style method signatures.
  
    1 │ interface Example {
  > 2 │   methodFunc(arg: string): number;
      │   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    3 │ }
    4 │ 
  
  ℹ Consistently using a single style of method signatures helps improve readability and consistency.
  
  ℹ Property-style function declarations also allow for stricter type checking when the strictFunctionTypes compiler option is enabled.
  
  ℹ If this isn’t what you want, consider changing the style option in the rule’s settings.
  
  ℹ This rule is still being actively worked on, so it may be missing features or have rough edges. Visit https://github.com/biomejs/biome/issues/8780 for more information or to report possible bugs.
  
  ℹ This rule belongs to the nursery group, which means it is not yet stable and may change in the future. Visit https://biomejs.dev/linter/#nursery for more information.
  

type Generic<T, U> = {
  methodFunc(arg: T): U;
}

code-block.ts:2:3 lint/nursery/useConsistentMethodSignatures ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

  ℹ Prefer using property-style over method-style method signatures.
  
    1 │ type Generic<T, U> = {
  > 2 │   methodFunc(arg: T): U;
      │   ^^^^^^^^^^^^^^^^^^^^^^
    3 │ }
    4 │ 
  
  ℹ Consistently using a single style of method signatures helps improve readability and consistency.
  
  ℹ Property-style function declarations also allow for stricter type checking when the strictFunctionTypes compiler option is enabled.
  
  ℹ If this isn’t what you want, consider changing the style option in the rule’s settings.
  
  ℹ This rule is still being actively worked on, so it may be missing features or have rough edges. Visit https://github.com/biomejs/biome/issues/8780 for more information or to report possible bugs.
  
  ℹ This rule belongs to the nursery group, which means it is not yet stable and may change in the future. Visit https://biomejs.dev/linter/#nursery for more information.
  

type Union =
  | {
    foo(bar: number): number;
  }
  | 4;

code-block.ts:3:5 lint/nursery/useConsistentMethodSignatures ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

  ℹ Prefer using property-style over method-style method signatures.
  
    1 │ type Union =
    2 │   | {
  > 3 │     foo(bar: number): number;
      │     ^^^^^^^^^^^^^^^^^^^^^^^^^
    4 │   }
    5 │   | 4;
  
  ℹ Consistently using a single style of method signatures helps improve readability and consistency.
  
  ℹ Property-style function declarations also allow for stricter type checking when the strictFunctionTypes compiler option is enabled.
  
  ℹ If this isn’t what you want, consider changing the style option in the rule’s settings.
  
  ℹ This rule is still being actively worked on, so it may be missing features or have rough edges. Visit https://github.com/biomejs/biome/issues/8780 for more information or to report possible bugs.
  
  ℹ This rule belongs to the nursery group, which means it is not yet stable and may change in the future. Visit https://biomejs.dev/linter/#nursery for more information.
  

type Intersection =
  {
    qux(quux: number): "quuux";
  } & { foo: string };

code-block.ts:3:5 lint/nursery/useConsistentMethodSignatures ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

  ℹ Prefer using property-style over method-style method signatures.
  
    1 │ type Intersection =
    2 │   {
  > 3 │     qux(quux: number): “quuux”;
      │     ^^^^^^^^^^^^^^^^^^^^^^^^^^^
    4 │   } & { foo: string };
    5 │ 
  
  ℹ Consistently using a single style of method signatures helps improve readability and consistency.
  
  ℹ Property-style function declarations also allow for stricter type checking when the strictFunctionTypes compiler option is enabled.
  
  ℹ If this isn’t what you want, consider changing the style option in the rule’s settings.
  
  ℹ This rule is still being actively worked on, so it may be missing features or have rough edges. Visit https://github.com/biomejs/biome/issues/8780 for more information or to report possible bugs.
  
  ℹ This rule belongs to the nursery group, which means it is not yet stable and may change in the future. Visit https://biomejs.dev/linter/#nursery for more information.
  

Valid

interface Prop {
  propFunc: (arg: string) => number;
}

type Thing<T> = {
  genericProp: <U>(arg: U) => T;
}

type Callback = () => void;

Classes (as well as interfaces lacking function declarations) are always ignored:

interface Example {
  notAFunc: number;
}

class Foo {
  methodFunc(arg: string): number;
}

Options

style

The desired method signature style to enforce.
Possible values are either "method" or "property".

Default: "property"²

Examples for "style": "method"

biome.json

{
  "linter": {
    "rules": {
      "nursery": {
        "useConsistentMethodSignatures": {
          "options": {
            "style": "method"
          }
        }
      }
    }
  }
}

interface Blah {
  propFunc: (arg: string) => void;
}

code-block.ts:2:3 lint/nursery/useConsistentMethodSignatures ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

  ℹ Prefer using method-style over property-style method signatures.
  
    1 │ interface Blah {
  > 2 │   propFunc: (arg: string) => void;
      │   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    3 │ }
    4 │ 
  
  ℹ Consistently using a single style of method signatures helps improve readability and consistency.
  
  ℹ If this isn’t what you want, consider changing the style option in the rule’s settings.
  
  ℹ This rule is still being actively worked on, so it may be missing features or have rough edges. Visit https://github.com/biomejs/biome/issues/8780 for more information or to report possible bugs.
  
  ℹ This rule belongs to the nursery group, which means it is not yet stable and may change in the future. Visit https://biomejs.dev/linter/#nursery for more information.
  

type Generic = {
  propFunc: <T, U>(arg: T) => U;
}

code-block.ts:2:3 lint/nursery/useConsistentMethodSignatures ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

  ℹ Prefer using method-style over property-style method signatures.
  
    1 │ type Generic = {
  > 2 │   propFunc: <T, U>(arg: T) => U;
      │   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    3 │ }
    4 │ 
  
  ℹ Consistently using a single style of method signatures helps improve readability and consistency.
  
  ℹ If this isn’t what you want, consider changing the style option in the rule’s settings.
  
  ℹ This rule is still being actively worked on, so it may be missing features or have rough edges. Visit https://github.com/biomejs/biome/issues/8780 for more information or to report possible bugs.
  
  ℹ This rule belongs to the nursery group, which means it is not yet stable and may change in the future. Visit https://biomejs.dev/linter/#nursery for more information.
  

type OK = {
  flubber(arg: number): number;
}

Related links

• Disable a rule
• Configure the code fix
• Rule options
• Source Code
• Test Cases

Footnotes

1. From a purely type-theoretical perspective, bivariance technically refers to a type being both covariant and contravariant at once (A ⊆ B implies T<A> ≣ T<B>).
   In practice, this is only true for pathological types like type T<A> = number, and so is often used to refer to a type being either covariant or contravariant (which simply requires T<A> and T<B> to have some non-zero amount of overlap). ↩

2. Chosen to allow stricter type checks under the aforementioned strictFunctionTypes. ↩