oxc-project/oxc · error · OxcDiagnostic

Expecting object for eslint/no-magic-numbers configuration

Error message

Expecting object for eslint/no-magic-numbers configuration

What it means

Configuration-load diagnostic from oxlint's eslint/no-magic-numbers rule (crates/oxc_linter/src/rules/eslint/no_magic_numbers.rs:85). NoMagicNumbersConfig::try_from expects the ESLint array form where the options object sits at index 0 (the config layer wraps rule options as Value::Array and the rule reads raw.get(0)); when there is no options object there — a bare scalar, an empty array, or a shape produced by hand-written/unnormalized configs or direct API calls — it returns this 'Expecting object' diagnostic. Note that from_configuration (line 308) calls try_from(...).unwrap(), so a bad shape aborts config loading with this message instead of being reported as a soft config warning.

Source

Thrown at crates/oxc_linter/src/rules/eslint/no_magic_numbers.rs:85

    /// When true, numeric literals used as TypeScript numeric literal types are ignored.
    ignore_numeric_literal_types: bool,
    /// When true, numeric literals in readonly class properties are ignored.
    ignore_readonly_class_properties: bool,
    /// When true, numeric literals used to index TypeScript types are ignored.
    ignore_type_indexes: bool,
}

impl TryFrom<&serde_json::Value> for NoMagicNumbersConfig {
    type Error = OxcDiagnostic;

    fn try_from(raw: &serde_json::Value) -> Result<Self, Self::Error> {
        if raw.is_null() {
            return Ok(NoMagicNumbersConfig::default());
        }

        raw.get(0).map_or_else(
            || {
                Err(OxcDiagnostic::warn(
                    "Expecting object for eslint/no-magic-numbers configuration",
                ))
            },
            |object| {
                fn get_bool_property(object: &serde_json::Value, index: &str) -> bool {
                    object.get(index).and_then(serde_json::Value::as_bool).unwrap_or_default()
                }
                Ok(Self {
                    ignore: object
                        .get("ignore")
                        .and_then(serde_json::Value::as_array)
                        .map(|v| {
                            v.iter()
                                .map(|v| {
                                    if v.is_number() {
                                        NoMagicNumbersNumber::Float(v.as_f64().unwrap())
                                    } else {
                                        NoMagicNumbersNumber::BigInt(v.as_str().unwrap().to_owned())

View on GitHub (pinned to e1e7af627c)

Solutions

  1. Write the rule config in the standard ESLint array form: "no-magic-numbers": ["error", { "enforceConst": true, "ignore": [1, 2] }]
  2. Validate .oxlintrc.json against the documented schema and re-run oxlint --version-matched configs after upgrades
  3. If invoking the linter programmatically, pass Value::Null (defaults) or Value::Array([optionsObject]) — never a bare scalar — to from_configuration
  4. Report a bug to the oxc repo if the normal config loader itself triggers this, since the loader is expected to always wrap options into an array

Example fix

// .oxlintrc.json — before (malformed options shape)
"no-magic-numbers": "strict"

// after
"no-magic-numbers": ["error", { "enforceConst": true }]
Defensive patterns

Strategy: validation

Validate before calling

// Validate the no-magic-numbers entry shape before running oxlint
function validateRuleConfig(name, value) {
  if (name !== 'no-magic-numbers') return true;
  if (value === 'error' || value === 'warn' || value === 'off') return true; // severity-only
  if (Array.isArray(value) && (value.length === 1 || typeof value[1] === 'object')) return true;
  console.error(`bad config shape for ${name}`);
  return false;
}

Type guard

const isNoMagicNumbersConfig = (v) =>
  v == null ||
  (Array.isArray(v) && (v.length === 0 || (typeof v[0] === 'object' && v[0] !== null)));

Try / catch

try {
  NoMagicNumbers.from_configuration(value);
} catch (e) {
  // unwrap() on a non-array/non-null options value panics with this diagnostic;
  // log it as a config error and fall back to default options
}

Prevention

When it happens

Trigger: Calling NoMagicNumbers::from_configuration with a non-array, non-null serde_json::Value (e.g. json!("strict"), json!(42), or json!([])); supplying rule options in a shape the config normalizer does not produce, such as nested or duplicated options objects in .oxlintrc.json overrides or programmatic LintService/napi usage that bypasses normalization.

Common situations: Hand-editing .oxlintrc.json or extends-chains that produce unexpected rule-config shapes; tools that generate oxlint configs from ESLint configs incorrectly; API/napi integrations passing options directly instead of the severity+options array form; version differences between oxlint releases changing accepted shapes.

Related errors

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