biome style/useNumberNamespace: fix changes program behavior

Hypothesis Nemotron 3 Super predicted to fire fired 1×

If `Number` is reassigned, the fix uses the reassigned value instead of the built-in constructor.

Program

Output

1

1reassigned

Judge Nemotron 3 Ultra advisory real · medium

The rule rewrites the global `parseInt` call to `Number.parseInt`, but the program declares a local variable named `Number` that shadows the global namespace. The documentation assumes the global `Number` object, so the fix changes the function being called and alters the program's output.

Explanation Nemotron 3 Super unverified

The original code calls the global `parseInt` function, which converts `'1'` to the number `1`. After rewriting, it calls `Number.parseInt`, a method on the locally defined object that returns the string `'1reassigned'`. Since these are different functions with distinct behaviors, the change alters program output and is not semantics‑preserving.

Reproduce

file

prog.js (the before program)

minimized program

r1-p002.js

evidence sheet

r1-p002.md

regression fixture

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

node prog.js
bunx @biomejs/biome lint --only=style/useNumberNamespace --write prog.js
node prog.js

Upstream search GitHub issues Tavily Nemotron 3 Super + Ultra

useNumberNamespace fix · style/useNumberNamespace global shadowing · parseInt call without namespace qualifier · Number variable reassignment affecting built-in

• related biomejs/biome/issues/1228 same rule (useNumberNamespace) but different construct (implementation request vs shadowing bug)
• related biomejs/biome/issues/3578 same rule (useNumberNamespace) but different construct (Infinity error message vs parseInt shadowing)
• related biomejs/biome/issues/2075 same rule (useNumberNamespace) but different construct (isNaN semantic difference vs parseInt shadowing)

Details

program

Reassigned Number variable

hazard

If `Number` is reassigned, the fix uses the reassigned value instead of the built-in constructor.

oracle

stdout before: 1 stdout after: 1reassigned

run

2026-10-17T21-04-15-156Z-qk6e-biome-style_useNumberNamespace

--- orig.js	2026-10-17 17:04:25.492627017 -0400
+++ fixed.js	2026-10-17 17:04:25.766630125 -0400
@@ -1,3 +1,3 @@
 "use strict";
 let Number = { parseInt: s => s + 'reassigned' };
-console.log(parseInt('1'));
+console.log(Number.parseInt('1'));

Summary

- Name: useNumberNamespace
- Fix: safe
- Default severity: info
- Available from version: 1.5.0
- Diagnostic category: lint/style/useNumberNamespace


Description

 Use the `Number` properties instead of global ones.

 _ES2015_ moved some globals into the `Number` properties for consistency.

 The rule doesn't report the globals `isFinite` and `isNaN` because they have a slightly different behavior to their corresponding `Number`'s properties `Number.isFinite` and `Number.isNaN`.
 You can use the dedicated rules [noGlobalIsFinite](https://biomejs.dev/linter/rules/no-global-is-finite/) and  [noGlobalIsNan](https://biomejs.dev/linter/rules/no-global-is-nan/) to enforce the use of `Number.isFinite` and `Number.isNaN`.

Examples

Invalid

 ```js,expect_diagnostic
 parseInt("1"); // true
 ```

 ```js,expect_diagnostic
 parseFloat("1.1"); // true
 ```

 ```js,expect_diagnostic
 NaN; // true
 ```

 ```js,expect_diagnostic
 Infinity; // true
 ```

 ```js,expect_diagnostic
 -Infinity; // true
 ```

Valid

 ```js
 Number.parseInt("1"); // false
 ```

 ```js
 Number.parseFloat("1.1"); // false
 ```

 ```js
 Number.NaN; // false
 ```

 ```js
 Number.POSITIVE_INFINITY; // false
 ```

 ```js
 Number.NEGATIVE_INFINITY; // false
 ```