oxc-project/oxc · warning · OxcDiagnostic

Prefer the spread operator (`...`) over {bad_method}

Error message

Prefer the spread operator (`...`) over {bad_method}

What it means

This is the oxlint rule `unicorn/prefer-spread` (category `style`, `conditional_fix`). It reports uses of older array-copy/creation APIs where the spread operator `...` is equivalent and clearer: `Array.from(x)` with a single non-object argument, `array.concat(...)`, and zero/one-argument `array.slice()` used as a copy, plus `Array.of`-style patterns handled by the same matcher.

Source

Thrown at crates/oxc_linter/src/rules/unicorn/prefer_spread.rs:13

use cow_utils::CowUtils;
use oxc_ast::{
    AstKind,
    ast::{CallExpression, Expression, match_member_expression},
};
use oxc_diagnostics::OxcDiagnostic;
use oxc_macros::declare_oxc_lint;
use oxc_span::{GetSpan, Span};

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

fn unicorn_prefer_spread_diagnostic(span: Span, bad_method: &str) -> OxcDiagnostic {
    OxcDiagnostic::warn(format!("Prefer the spread operator (`...`) over {bad_method}"))
        .with_help("The spread operator (`...`) is more concise and readable.")
        .with_label(span)
}

#[derive(Debug, Default, Clone)]
pub struct PreferSpread;

declare_oxc_lint!(
    /// ### What it does
    ///
    /// Enforces the use of [the spread operator (`...`)](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Spread_syntax) over outdated patterns.
    ///
    /// ### Why is this bad?
    ///
    /// Using the spread operator is more concise and readable.
    ///
    /// ### Examples
    ///

View on GitHub (pinned to e1e7af627c)

Solutions

1. Replace `Array.from(x)` with `[...x]` (only when `x` is an iterable, not an array-like object).
2. Replace copy idioms: `arr.concat()` / `arr.slice()` → `[...arr]`; `arr.concat(other)` → `[...arr, ...other]`.
3. Run `oxlint --fix` and review — the fix is applied only where the rule proved it safe (conditional_fix).
4. If you target environments without spread support or rely on `Array.from`'s array-like handling, disable the rule or add a line-level disable comment.

Example fix

// before
const copy = Array.from(new Set([1, 2]));
const merged = a.concat(b);

// after
const copy = [...new Set([1, 2])];
const merged = [...a, ...b];

// Prefer spread idioms up front
const copy = [...arr];
const merged = [...a, ...b];
const fromSet = [...someSet];
// CI: npx oxlint --deny-warn unicorn/prefer-spread src/

When it happens

Trigger: `Array.from(set)`, `Array.from(iterable)` with exactly one argument that is not an object (the map-function/array-like forms are skipped); `someArray.concat(other)`; `someArray.slice()` or `.slice(n)` on an expression known to be an array (array literals and `this` receivers are exempted). Computed or optional member accesses are ignored.

Common situations: Codebases predating ES2015 spread, tutorials that copy arrays with `arr.slice(0)` or `arr.concat()`, converting Sets/Maps to arrays with `Array.from`; the fix is conditional because `Array.from` also accepts array-likes and iterables where spread is not always interchangeable in older targets.

Related errors

• Prefer consistent types when spreading a ternary in an array
• Prefer `{} {}` over `{} {}` to check {}.
• Invalid escape sequence in template literal.
• No spaces inside empty pair of braces allowed
• Use uppercase characters for the value of the escape sequenc

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