oxc-project/oxc · warning · OxcDiagnostic

These overloads can be combined into one signature with a re

Error message

These overloads can be combined into one signature with a rest parameter.

What it means

Diagnostic from oxlint's `typescript/unified-signatures` rule (port of @typescript-eslint/unified-signatures). It fires only on TypeScript files and reports when a group of exactly two overload signatures can be merged into one: their parameters are identical up to the common prefix and the longer signature simply adds a trailing rest parameter, so the longer signature already accepts every call the pair accepted. The rule scans top-level function overloads, TS module blocks, interface bodies, type-literal members, and class method overloads.

Source

Thrown at crates/oxc_linter/src/rules/typescript/unified_signatures.rs:30

};
use oxc_diagnostics::{LabeledSpan, OxcDiagnostic};
use oxc_macros::declare_oxc_lint;
use oxc_span::{GetSpan, Span};
use rustc_hash::{FxHashMap, FxHashSet};
use schemars::JsonSchema;
use serde::{Deserialize, Serialize};

use crate::{
    AstNode,
    context::{ContextHost, LintContext},
    rule::{DefaultRuleConfig, Rule},
};

fn unified_signatures_diagnostic<L: Into<LabeledSpan>, T: IntoIterator<Item = L>>(
    message: String,
    labels: T,
) -> OxcDiagnostic {
    OxcDiagnostic::warn(message).with_labels(labels)
}

#[derive(Debug, Default, Clone, Deserialize, Serialize, JsonSchema)]
#[serde(default, rename_all = "camelCase", deny_unknown_fields)]
pub struct UnifiedSignaturesOptions {
    /// Whether to ignore parameter name differences when comparing signatures. If `false`, signatures
    /// will not be considered unifiable if they have parameters in the same position with different
    /// names, even if the parameter types are the same.
    ignore_differently_named_parameters: bool,
    /// Whether to ignore JSDoc differences when comparing signatures. If `false`, signatures will not
    /// be considered unifiable if the closest leading block comments for the signatures are different,
    /// even if the signatures themselves are identical.
    #[serde(rename = "ignoreOverloadsWithDifferentJSDoc")]
    ignore_overloads_with_different_jsdoc: bool,
}

#[derive(Debug, Default, Clone, Deserialize, Serialize)]
pub struct UnifiedSignatures(UnifiedSignaturesOptions);

View on GitHub (pinned to e1e7af627c)

Solutions

1. Delete the shorter overload and keep the single signature that already includes the rest parameter.
2. If the split is intentional because each overload has different JSDoc, enable the `ignoreOverloadsWithDifferentJSDoc` option in .oxlintrc.json.
3. If the overloads deliberately differ only by parameter names, enable `ignoreDifferentlyNamedParameters`.
4. Suppress the single intentional case with an inline disable comment for `typescript/unified-signatures`.

Example fix

// before
declare function log(msg: string): void;
declare function log(msg: string, ...meta: unknown[]): void;
// after
declare function log(msg: string, ...meta: unknown[]): void;

// .oxlintrc.json — configure before enabling, so intentional splits do not fail CI
{
  "rules": {
    "typescript/unified-signatures": [
      "warn",
      { "ignoreDifferentlyNamedParameters": true, "ignoreOverloadsWithDifferentJSDoc": true }
    ]
  }
}

When it happens

Trigger: A .ts/.d.ts file containing two same-named signatures where the shorter does not end in a rest parameter and the longer adds only `...rest`, e.g. `declare function log(msg: string): void;` next to `declare function log(msg: string, ...meta: unknown[]): void;`. Equivalent method pairs in interfaces, type literals, and class overload sets are also scanned.

Common situations: Hand-maintained overload lists for logging, fetch wrappers, or query builders; declaration files where overloads accreted over years; teams enabling the `typescript` oxlint preset or migrating from typescript-eslint where this rule was already active.

Related errors

• This overload can be combined with another overload into one
• These overloads can be combined into one signature with an o
• This overload can be combined with another overload into one
• Type can be trivially inferred from the initializer
• Prefer using inline type specifiers instead of a top-level t

AI-assisted analysis of oxc-project/oxc@e1e7af627c (2026-08-20). Data as JSON: /api/errors/0f1ce87fd133a5cd. Report an issue: GitHub.