{"record":{"id":"19e68a8bdbf03f7a","repo":"oxc-project/oxc","slug":"inconsistent-assert-usage","errorCode":null,"errorMessage":"Inconsistent assert usage.","messagePattern":"Inconsistent assert usage\\.","errorType":"validation","errorClass":"OxcDiagnostic","httpStatus":null,"severity":"warning","filePath":"crates/oxc_linter/src/rules/unicorn/consistent_assert.rs","lineNumber":13,"sourceCode":"use oxc_ast::{\n    AstKind,\n    ast::{Expression, ImportDeclaration, ImportDeclarationSpecifier, ModuleExportName},\n};\nuse oxc_diagnostics::OxcDiagnostic;\nuse oxc_macros::declare_oxc_lint;\nuse oxc_semantic::SymbolId;\nuse oxc_span::Span;\n\nuse crate::{AstNode, context::LintContext, rule::Rule};\n\nfn consistent_assert_diagnostic(assert_identifier: &str, span: Span) -> OxcDiagnostic {\n    OxcDiagnostic::warn(\"Inconsistent assert usage.\")\n        .with_help(format!(\"Prefer `{assert_identifier}.ok(...)` over `{assert_identifier}(...)`.\"))\n        .with_label(span)\n}\n\n#[derive(Debug, Default, Clone)]\npub struct ConsistentAssert;\n\ndeclare_oxc_lint!(\n    /// ### What it does\n    ///\n    /// Enforces consistent usage of the `assert` module.\n    ///\n    /// ### Why is this bad?\n    ///\n    /// Inconsistent usage of the `assert` module can make code\n    /// harder to follow and understand.\n    ///\n    /// `assert.ok(...)` is preferred as it makes the intent of","sourceCodeStart":1,"sourceCodeEnd":31,"githubUrl":"https://github.com/oxc-project/oxc/blob/e1e7af627c8843ab64044ed466b128fcc21a035b/crates/oxc_linter/src/rules/unicorn/consistent_assert.rs#L1-L31","documentation":"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.","triggerScenarios":"`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.","commonSituations":"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.","solutions":["Change `assert(expr)` to `assert.ok(expr)` — `oxlint --fix` rewrites it automatically.","If direct calls are intentional in some files, disable the rule for those files via overrides in .oxlintrc.json.","Standardize on the named assertion helpers (`assert.ok`, `assert.equal`, ...) in your style guide."],"exampleFix":"// before\nimport assert from 'node:assert';\nassert(divide(10, 2) === 5);\n// after\nimport assert from 'node:assert';\nassert.ok(divide(10, 2) === 5);","handlingStrategy":"validation","validationCode":null,"typeGuard":null,"tryCatchPattern":null,"preventionTips":["Use `assert.ok(...)` for truthiness assertions; never call the imported assert binding directly.","Standardize on named helpers (`assert.ok`, `assert.equal`, `assert.throws`) in your test style guide.","Run `oxlint --fix` in pre-commit so any stray `assert(x)` is rewritten automatically."],"tags":["oxlint","lint","unicorn","nodejs","assert","testing"],"backgroundTag":"node-assert-usage","analyzedSha":"e1e7af627c8843ab64044ed466b128fcc21a035b","analyzedAt":"2026-08-20T07:01:07.079Z","contentChangedAt":"2026-08-20T07:01:07.079Z","schemaVersion":2},"datasetVersion":"2026-09-14T00:17:10.932Z"}