useConsistentMethodSignatures (JavaScript)
Summary
Section titled “Summary”- Rule available since:
v2.3.14 - Diagnostic Category:
lint/style/useConsistentMethodSignatures - This rule isn’t recommended, so you need to enable it.
- This rule has an unsafe fix.
- The default severity of this rule is information.
- Sources:
How to configure
Section titled “How to configure”{ "linter": { "rules": { "style": { "useConsistentMethodSignatures": "error" } } }}Description
Section titled “Description”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.
Examples
Section titled “Examples”Invalid
Section titled “Invalid”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;}Options
Section titled “Options”The desired method signature style to enforce.
Possible values are either "method" or "property".
Default: "property", which enables stricter parameter checking with
strictFunctionTypes.
Examples for "style": "method"
Section titled “Examples for "style": "method"”{ "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;}Related links
Section titled “Related links”Copyright (c) 2023-present Biome Developers and Contributors.