oxc-project/oxc · warning · OxcDiagnostic

Inconsistent assert usage.

Error message

Inconsistent assert usage.

What it means

Diagnostic from oxlint's `unicorn/consistent-assert` rule. It enforces consistent use of Node's `assert` module: `assert.ok(...)` is preferred over calling the imported binding directly, because the bare call obscures that it is a truthiness check. The rule resolves the default import (or the `strict` named import) from `assert`, `node:assert`, `assert/strict`, or `node:assert/strict` through symbol resolution and flags every direct call of that binding.

Source

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

use oxc_ast::{
    AstKind,
    ast::{Expression, ImportDeclaration, ImportDeclarationSpecifier, ModuleExportName},
};
use oxc_diagnostics::OxcDiagnostic;
use oxc_macros::declare_oxc_lint;
use oxc_semantic::SymbolId;
use oxc_span::Span;

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

fn consistent_assert_diagnostic(assert_identifier: &str, span: Span) -> OxcDiagnostic {
    OxcDiagnostic::warn("Inconsistent assert usage.")
        .with_help(format!("Prefer `{assert_identifier}.ok(...)` over `{assert_identifier}(...)`."))
        .with_label(span)
}

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

declare_oxc_lint!(
    /// ### What it does
    ///
    /// Enforces consistent usage of the `assert` module.
    ///
    /// ### Why is this bad?
    ///
    /// Inconsistent usage of the `assert` module can make code
    /// harder to follow and understand.
    ///
    /// `assert.ok(...)` is preferred as it makes the intent of

View on GitHub (pinned to e1e7af627c)

Solutions

1. Change `assert(expr)` to `assert.ok(expr)` — `oxlint --fix` rewrites it automatically.
2. If direct calls are intentional in some files, disable the rule for those files via overrides in .oxlintrc.json.
3. Standardize on the named assertion helpers (`assert.ok`, `assert.equal`, ...) in your style guide.

Example fix

// before
import assert from 'node:assert';
assert(divide(10, 2) === 5);
// after
import assert from 'node:assert';
assert.ok(divide(10, 2) === 5);

When it happens

Trigger: `import assert from 'node:assert';` followed by `assert(divide(10, 2) === 5);` — also `import { strict as assert } from 'node:assert';` called directly. String-literal import specifiers such as `import { 'strict' as assert }` are skipped.

Common situations: Test suites and CLI tools mixing `assert(x)` with `assert.ok(x)`; code copied from older Node docs; enabling the `unicorn` (pedantic) preset which includes this rule.

Related errors

• Require a message for {matcher_name:?}.
• Do not import Node.js builtin module `{module_name}`
• `jest.setTimeout` should only be called in a global scope
• Do not call `jest.setTimeout` multiple times
• `jest.setTimeout` should be placed before any other jest met

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