eslint prefer-numeric-literals: fix changes program behavior

Hypothesis Nemotron 3 Super predicted to fire fired 1×

Missing semicolon causes next line's '(' to be interpreted as function call, breaking after rewrite due to altered precedence.

Program

Output

(no stdout)
TypeError: parseInt(...) is not a function

(no stdout)
TypeError: 503 is not a function

Judge Nemotron 3 Ultra advisory real · high

The program uses the result of parseInt('111110111', 2) as a callable function, but the fix replaces it with the numeric literal 503, which is not callable. The rule documentation presents the rewrite as equivalent for numeric value, but does not account for the call expression context, causing a crash where the original code threw a different error.

Explanation Nemotron 3 Super unverified

The original code attempts to call `parseInt` with two arguments but mistakenly treats it as if only one argument were provided due to missing parentheses or misinterpretation—however, the actual error arises because in the observed context, `parseInt` is not defined or has been overridden, causing a TypeError when trying to invoke it. After the rewrite, `parseInt` is replaced with the numeric literal `503`, so the expression becomes `let a = 503`, which succeeds. However, the subsequent IIFE is unaffected. The error shift from "parseInt is not a function" to "503 is not a function" indicates that the rewritten value `503` is now being treated as a callable in a context where a function was expected—likely due to another part of the code (not shown) attempting to invoke `a` as a function. Since `a` is now a number instead of a function, invoking it fails, changing the error type but preserving the fact that a non-function is being called. The fix altered the value’s type, breaking downstream usage that expected a function.

Reproduce

file

prog.js (the before program)

minimized program

r1-p006.js

evidence sheet

r1-p006.md

regression fixture

r1-p006.js the minimized program with a header stating the observed change, for the tool's test suite

node prog.js
npx eslint --no-config-lookup --rule 'prefer-numeric-literals: error' --fix prog.js
node prog.js

Upstream search GitHub issues Tavily Nemotron 3 Super + Ultra

prefer-numeric-literals fix · prefer-numeric-literals parseInt binary string · eslint prefer-numeric-literals radix 2 conversion · rule prefer-numeric-literals parseInt base two

• related eslint/eslint/issues/8913 same rule prefer-numeric-literals but about Number.parseInt not parseInt call expression
• related eslint/eslint/issues/2 IIFE wrapping issue same construct as the snippet shows an IIFE

Details

program

ASI with leading parenthesis

hazard

Missing semicolon causes next line's '(' to be interpreted as function call, breaking after rewrite due to altered precedence.

oracle

stderr before: TypeError: parseInt(...) is not a function stderr after: TypeError: 503 is not a function

run

2026-10-22T18-27-24-634Z-n55b-eslint-prefer-numeric-literals

--- orig.js	2026-10-22 14:27:32.532083215 -0400
+++ fixed.js	2026-10-22 14:27:35.136046154 -0400
@@ -1,2 +1,2 @@
-let a = parseInt('111110111', 2)
+let a = 0b111110111
 (function(){ console.log('called'); })()

Rule: prefer-numeric-literals
Fixable: code
Type: suggestion
Deprecated: no
Description: Disallow `parseInt()` and `Number.parseInt()` in favor of binary, octal, and hexadecimal literals
Docs: https://eslint.org/docs/latest/rules/prefer-numeric-literals

---
title: prefer-numeric-literals
rule_type: suggestion
---



The `parseInt()` and `Number.parseInt()` functions can be used to turn binary, octal, and hexadecimal strings into integers. As binary, octal, and hexadecimal literals are supported in ES6, this rule encourages use of those numeric literals instead of `parseInt()` or `Number.parseInt()`.

```js
0b111110111 === 503;
0o767 === 503;
```

## Rule Details

This rule disallows calls to `parseInt()` or `Number.parseInt()` if called with two arguments: a string; and a radix option of 2 (binary), 8 (octal), or 16 (hexadecimal).

Examples of **incorrect** code for this rule:

::: incorrect

```js
/*eslint prefer-numeric-literals: "error"*/

parseInt("111110111", 2) === 503;
parseInt(`111110111`, 2) === 503;
parseInt("767", 8) === 503;
parseInt("1F7", 16) === 503;
Number.parseInt("111110111", 2) === 503;
Number.parseInt("767", 8) === 503;
Number.parseInt("1F7", 16) === 503;
```

:::

Examples of **correct** code for this rule:

::: correct

```js
/*eslint prefer-numeric-literals: "error"*/

parseInt(1);
parseInt(1, 3);
Number.parseInt(1);
Number.parseInt(1, 3);

0b111110111 === 503;
0o767 === 503;
0x1F7 === 503;

a[parseInt](1,2);

parseInt(foo);
parseInt(foo, 2);
Number.parseInt(foo);
Number.parseInt(foo, 2);
```

:::

## Options

This rule has no options.

## When Not To Use It

If you want to allow use of `parseInt()` or `Number.parseInt()` for binary, octal, or hexadecimal integers, or if you are not using ES6 (because binary and octal literals are not supported in ES5 and below), you may wish to disable this rule.

## Compatibility

* **JSCS**: [requireNumericLiterals](https://jscs-dev.github.io/rule/requireNumericLiterals)