Skip to content

useConsistentMethodSignatures (JavaScript)

Language JavaScript (and super languages)
biome.json
{
"linter": {
"rules": {
"style": {
"useConsistentMethodSignatures": "error"
}
}
}
}

Enforce one syntax for functions declared in interfaces and type aliases.

TypeScript supports method syntax and property syntax:

interface Example {
method(arg: string): void;
property: (arg: string) => void;
}

The two forms can behave differently when the strictFunctionTypes compiler option is enabled. Function properties receive stricter parameter checks, while methods keep TypeScript’s more permissive compatibility behavior.

In this example, callers of Emitter may pass any Event. Narrowing the property parameter to SpecialEvent is therefore rejected, while TypeScript still accepts the method form:

interface Emitter {
method(arg: Event): void;
property: (arg: Event) => void;
}
interface SpecialEvent extends Event {
isBirthday: boolean;
}
interface SpecialEmitter extends Emitter {
method(arg: SpecialEvent): void;
property: (arg: SpecialEvent) => void; // Error with `strictFunctionTypes`
}

Type-system terminology With strictFunctionTypes, function properties check parameters contravariantly: a replacement function must accept every value accepted by the original function. Methods use TypeScript’s more permissive bivariant parameter checking, which allows the narrower SpecialEvent parameter above. See the TypeScript handbook for the formal rationale.

Using one form consistently avoids unexpected differences in type checking.

Without strictFunctionTypes, the two forms have the same parameter-checking behavior, so the choice is only stylistic.

interface Example {
methodFunc(arg: string): number;
}
code-block.ts:2:3 lint/style/useConsistentMethodSignatures  FIXABLE  ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

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

ℹ Unsafe fix: Convert to property-style signature.

1 1 │ interface Example {
2 │ - ··methodFunc(arg:·string):·number;
2 │ + ··methodFunc:·(arg:·string)·=>·number;
3 3 │ }
4 4 │

type Generic<T, U> = {
methodFunc(arg: T): U;
}
code-block.ts:2:3 lint/style/useConsistentMethodSignatures  FIXABLE  ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

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

ℹ Unsafe fix: Convert to property-style signature.

1 1 │ type Generic<T, U> = {
2 │ - ··methodFunc(arg:·T):·U;
2 │ + ··methodFunc:·(arg:·T)·=>·U;
3 3 │ }
4 4 │

type Union =
| {
foo(bar: number): number;
}
| 4;
code-block.ts:3:5 lint/style/useConsistentMethodSignatures  FIXABLE  ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

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

ℹ Unsafe fix: Convert to property-style signature.

1 1 │ type Union =
2 2 │ | {
3 │ - ····foo(bar:·number):·number;
3 │ + ····foo:·(bar:·number)·=>·number;
4 4 │ }
5 5 │ | 4;

type Intersection =
{
qux(quux: number): "quuux";
} & { foo: string };
code-block.ts:3:5 lint/style/useConsistentMethodSignatures  FIXABLE  ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

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

ℹ Unsafe fix: Convert to property-style signature.

1 1 │ type Intersection =
2 2 │ {
3 │ - ····qux(quux:·number):·"quuux";
3 │ + ····qux:·(quux:·number)·=>·"quuux";
4 4 │ } & { foo: string };
5 5 │

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;
}

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

Default: "property", which enables stricter parameter checking with strictFunctionTypes.

biome.json
{
"linter": {
"rules": {
"style": {
"useConsistentMethodSignatures": {
"level": "on",
"options": {
"style": "method"
}
}
}
}
}
}
interface Blah {
propFunc: (arg: string) => void;
}
code-block.ts:2:3 lint/style/useConsistentMethodSignatures  FIXABLE  ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

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

ℹ Unsafe fix: Convert to method-style signature.

1 1 │ interface Blah {
2 │ - ··propFunc:·(arg:·string)·=>·void;
2 │ + ··propFunc(arg:·string):·void;
3 3 │ }
4 4 │

type Generic = {
propFunc: <T, U>(arg: T) => U;
}
code-block.ts:2:3 lint/style/useConsistentMethodSignatures  FIXABLE  ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

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

ℹ Unsafe fix: Convert to method-style signature.

1 1 │ type Generic = {
2 │ - ··propFunc:·<T,·U>(arg:·T)·=>·U;
2 │ + ··propFunc<T,·U>(arg:·T):·U;
3 3 │ }
4 4 │

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