biome style/useNumberNamespace: fix changes program behavior

Hypothesis Nemotron 3 Super predicted to fire fired 1×

name collisions across scopes after a move (shadowing)

Program

Output

1

999

Judge Nemotron 3 Ultra advisory real · medium

The rule rewrites global parseInt to Number.parseInt assuming the global Number object, but the program declares a local const Number that shadows it. The documentation does not mention this shadowing case, so the fix changes behavior in plausible code where a variable named Number exists in scope.

Explanation Nemotron 3 Super unverified

The original call `parseInt('1')` refers to the global built-in function because no local variable named `parseInt` exists in scope; it returns 1. After rewriting, `Number.parseInt('1')` accesses the property of the locally declared constant `Number`, which overrides the global `Number` constructor and defines `parseInt` to return 999, changing the output. The rewrite alters which function is invoked due to the local binding of `Number`.

Reproduce

file

prog.js (the before program)

minimized program

r2-p008.js

evidence sheet

r2-p008.md

regression fixture

r2-p008.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 parseInt · style useNumberNamespace shadowing Number · style useNumberNamespace local variable conflict

• related biomejs/biome/issues/1228 same rule (useNumberNamespace) but about implementing the rule, not a fix-changes-behavior defect
• related biomejs/biome/issues/3578 same rule (useNumberNamespace) but about incorrect error message for Infinity, not fix-changes-behavior on parseInt
• duplicate biomejs/biome/issues/2075 same rule (useNumberNamespace) and same defect class: fix replaces global isNaN/parseInt with Number.namespaced version which has different semantics when Number is shadowed

Details

program

Name collision after move due to shadowing

hazard

name collisions across scopes after a move (shadowing)

oracle

stdout before: 1 stdout after: 999

run

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

--- orig.js	2026-10-17 17:04:36.450751086 -0400
+++ fixed.js	2026-10-17 17:04:36.715754081 -0400
@@ -1,4 +1,4 @@
 {
   const Number = { parseInt: () => 999 };
-  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
 ```