feat(linter): implement typescript/method-signature-style#19599
Conversation
How to use the Graphite Merge QueueAdd either label to this PR to merge it via the merge queue:
You must have a Graphite account in order to use the merge queue. Sign up using this link. An organization admin has enabled the Graphite Merge Queue in this repository. Please do not merge from GitHub as this will restart CI on PRs being processed by the merge queue. This stack of pull requests is managed by Graphite. Learn more about stacking. |
Merging this PR will not alter performance
Comparing Footnotes
|
5f1cadb to
7d4947c
Compare
c5ab142 to
322712d
Compare
c2c0f31 to
971cefc
Compare
46c35cc to
46177dd
Compare
971cefc to
78391e1
Compare
There was a problem hiding this comment.
Pull request overview
This pull request implements a new TypeScript ESLint rule method-signature-style that enforces consistent method signature syntax in TypeScript interfaces and type literals.
Changes:
- Implements the
typescript/method-signature-stylerule with two configuration modes: "property" (default, enforcing arrow function syntax) and "method" (enforcing method shorthand syntax) - Handles complex cases including method overloads,
thisreturn types, module declarations, and various edge cases with proper fix suggestions - Integrates the new rule into the linter infrastructure with comprehensive test coverage
Reviewed changes
Copilot reviewed 3 out of 5 changed files in this pull request and generated 1 comment.
Show a summary per file
| File | Description |
|---|---|
| crates/oxc_linter/src/rules/typescript/method_signature_style.rs | Main implementation of the method signature style rule with fix generation and edge case handling |
| crates/oxc_linter/src/snapshots/typescript_method_signature_style.snap | Test snapshots showing error messages and fix suggestions for various test cases |
| crates/oxc_linter/src/rules.rs | Module declaration for the new rule |
| crates/oxc_linter/src/generated/rules_enum.rs | Generated integration code for the rule enum |
| crates/oxc_linter/src/generated/rule_runner_impls.rs | Generated runner implementation specifying AST node types the rule operates on |
| use schemars::JsonSchema; | ||
| use serde::{Deserialize, Serialize}; | ||
|
|
||
| use oxc_ast::{ | ||
| AstKind, | ||
| ast::{ | ||
| TSMethodSignature, TSMethodSignatureKind, TSPropertySignature, TSSignature, TSThisType, | ||
| TSType, TSTypeAnnotation, | ||
| }, | ||
| }; | ||
| use oxc_ast_visit::{Visit, walk}; | ||
| use oxc_diagnostics::OxcDiagnostic; | ||
| use oxc_macros::declare_oxc_lint; | ||
| use oxc_span::{GetSpan, Span}; | ||
|
|
||
| use crate::{ | ||
| AstNode, | ||
| context::{ContextHost, LintContext}, | ||
| rule::{DefaultRuleConfig, Rule}, |
There was a problem hiding this comment.
The import order should follow the codebase convention: std imports, then oxc_* crates (alphabetically), then other external crates (alphabetically), then crate:: imports. Currently, schemars and serde are placed before oxc_ast, which is inconsistent with the pattern seen in other files like class_literal_property_style.rs.
|
I was wondering if we could revisit this rule, it is important in my codebase. |
I'm happy to accept contributions to implement this rule - I closed this PR because I ran out of time to get it merged. Thanks! |

No description provided.