oxc-project/oxc · info · OxcDiagnostic

Member '{name}' of the import declaration should be sorted a

Error message

Member '{name}' of the import declaration should be sorted alphabetically.

What it means

oxlint `eslint/sort-imports`: within a single import declaration the named specifiers are not alphabetically sorted. `sort_members_alphabetically_diagnostic` (sort_imports.rs:36) formats 'Member \'{name}\' of the import declaration should be sorted alphabetically.' This is the member-sort half of the rule, controlled independently by `ignoreMemberSort`.

Source

Thrown at crates/oxc_linter/src/rules/eslint/sort_imports.rs:36

    context::LintContext,
    rule::{DefaultRuleConfig, Rule},
};

fn unexpected_syntax_order_diagnostic(
    curr_kind: &ImportKind,
    prev_kind: &ImportKind,
    span: Span,
) -> OxcDiagnostic {
    OxcDiagnostic::warn(format!("Expected '{curr_kind}' syntax before '{prev_kind}' syntax."))
        .with_label(span)
}

fn sort_imports_alphabetically_diagnostic(span: Span) -> OxcDiagnostic {
    OxcDiagnostic::warn("Imports should be sorted alphabetically.").with_label(span)
}

fn sort_members_alphabetically_diagnostic(name: &str, span: Span) -> OxcDiagnostic {
    OxcDiagnostic::warn(format!(
        "Member '{name}' of the import declaration should be sorted alphabetically."
    ))
    .with_label(span)
}

#[derive(Debug, Default, Clone, Deserialize)]
pub struct SortImports(Box<SortImportsOptions>);

#[derive(Debug, Default, Clone, JsonSchema, Deserialize)]
#[serde(rename_all = "camelCase", default, deny_unknown_fields)]
pub struct SortImportsOptions {
    /// When `true`, the rule ignores case-sensitivity when sorting import names.
    ignore_case: bool,
    /// When `true`, the rule ignores the sorting of import declarations (the order of `import` statements).
    ignore_declaration_sort: bool,
    /// When `true`, the rule ignores the sorting of import members within a single import declaration.
    ignore_member_sort: bool,
    /// When `true`, the rule allows import groups separated by blank lines to be treated independently.

View on GitHub (pinned to e1e7af627c)

Solutions

  1. Sort the named specifiers: `import { b, a } from 'mod'` becomes `import { a, b } from 'mod'`.
  2. Use your editor's 'organize imports'/'sort members' action, which fixes this class wholesale.
  3. Set `ignoreMemberSort: true` if your team does not want intra-declaration ordering enforced.

Example fix

// before
import { useState, useEffect, memo } from 'react';

// after
import { useEffect, memo, useState } from 'react';
Defensive patterns

Strategy: validation

Prevention

When it happens

Trigger: `import { b, a } from 'mod.js'` — specifiers within one declaration out of order; also fires for type/value mixed specifiers compared by name. `ignoreCase: true` makes the comparison case-insensitive.

Common situations: Auto-added imports by an IDE appending to the end; merge conflicts combining two specifier lists; large barrel imports edited by hand.

Related errors


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