oxc-project/oxc · warning · OxcDiagnostic

Prefer bigint literals over `BigInt(...)`.

Error message

Prefer bigint literals over `BigInt(...)`.

What it means

Lint diagnostic from oxlint's `unicorn/prefer-bigint-literals` rule. Calling `BigInt(123)` or `BigInt('123')` with a literal argument is a runtime function call plus (for strings) a parse, when the `123n` literal syntax compiles directly to the same value. The rule flags `BigInt(...)` calls whose argument is a numeric or numeric-string literal and requires the literal form.

Source

Thrown at crates/oxc_linter/src/rules/unicorn/prefer_bigint_literals.rs:10

use oxc_ast::{AstKind, ast::Expression};
use oxc_diagnostics::OxcDiagnostic;
use oxc_macros::declare_oxc_lint;
use oxc_span::{GetSpan, Span};
use oxc_syntax::number::NumberBase;

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

fn prefer_bigint_literals_diagnostic(span: Span) -> OxcDiagnostic {
    OxcDiagnostic::warn("Prefer bigint literals over `BigInt(...)`.")
        .with_help("Use a bigint literal (e.g. `123n`) instead of calling `BigInt` with a literal argument.")
        .with_label(span)
}

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

declare_oxc_lint!(
    /// ### What it does
    ///
    /// Requires using BigInt literals (e.g. `123n`) instead of calling the `BigInt()` constructor
    /// with literal arguments such as numbers or numeric strings
    ///
    /// ### Why is this bad?
    ///
    /// Using `BigInt(…)` with literal values is unnecessarily verbose and less idiomatic than using
    /// a BigInt literal.
    ///

View on GitHub (pinned to e1e7af627c)

Solutions

1. Replace `BigInt(123)` with `123n` and `BigInt('0x10')` with `0x10n`.
2. Run `oxlint --fix` for the mechanical rewrite.
3. Keep `BigInt(dynamicValue)` untouched — the rule only flags literal arguments; if a variable holds the literal in string form (config/env), converting needs a runtime call, so suppress if flagged by a broader custom rule.
4. Disable the rule via `.oxlintrc.json` if the codebase must compile without bigint literal support (very old TS `target`).

Example fix

// before
const MAX = BigInt(9007199254740993); // precision already lost!

// after
const MAX = 9007199254740993n;

// oxlint --fix --filter unicorn/prefer-bigint-literals src/
// CI gate: oxlint --deny-warnings src/

When it happens

Trigger: `const id = BigInt(9007199254740993);`, `BigInt('123')`, `BigInt(0x10)` — any CallExpression named `BigInt` with exactly one literal argument (number literal or string containing a decimal/hex number). Detected during oxlint runs on CallExpressions.

Common situations: Developers who learned `BigInt()` as 'the constructor' and use it uniformly, or code generated before bigint literal support in the toolchain. Note the real trap this rule points at: `BigInt(9007199254740993)` silently loses precision because the *number* literal is rounded to a double BEFORE BigInt sees it — `9007199254740993n` is correct. Common when enabling unicorn category on payment/ID-heavy code.

Related errors

• Don't use a zero fraction in the number.
• Don't use a dangling dot in the number.
• Unexpected number literal prefix in uppercase.
• Unexpected exponential notation in uppercase.
• Unexpected hexadecimal digits in lowercase.

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