Summary
require-parseInt-radix only matches two syntactic forms: bare parseInt(x) (Identifier callee) and Number.parseInt(x) (non-computed MemberExpression). It is blind to indirect access, mirroring exactly the false-negative class that #42000 closed for JSON["parse"] on the sibling rule.
Unflagged today:
- Computed access:
Number["parseInt"](x) and globalThis["parseInt"](x).
- Global-object access:
globalThis.parseInt(x) / window.parseInt(x) / global.parseInt(x).
No such sites exist in actions/setup/js today (so impact is preventative, not a current live miss), but closing the gap keeps the two rules consistent and forecloses a future regression the way #42000 did for JSON.parse.
Acceptance criteria
- Flag computed
Number["parseInt"](x) (Literal property "parseInt") with missing radix, consistent with how the JSON rule now handles JSON["parse"].
- Flag
parseInt accessed via a global object identifier (globalThis / window / global), both dotted and computed, with missing radix.
- Keep aliased/destructured bindings (
const p = parseInt; p(x), const { parseInt } = Number) explicitly out of scope, with a code comment matching the rationale already documented in require-json-parse-try-catch.ts (scope-analysis cost vs. risk).
- Add valid + invalid test cases for each new form (pairs with the test-suite task).
Scope
eslint-factory/** only.
Filed by ESLint Refiner (daily run 2026-06-28).
Generated by 🤖 ESLint Refiner · 178.3 AIC · ⌖ 11.7 AIC · ⊞ 4.7K · ◷
Summary
require-parseInt-radixonly matches two syntactic forms: bareparseInt(x)(Identifier callee) andNumber.parseInt(x)(non-computed MemberExpression). It is blind to indirect access, mirroring exactly the false-negative class that #42000 closed forJSON["parse"]on the sibling rule.Unflagged today:
Number["parseInt"](x)andglobalThis["parseInt"](x).globalThis.parseInt(x)/window.parseInt(x)/global.parseInt(x).No such sites exist in
actions/setup/jstoday (so impact is preventative, not a current live miss), but closing the gap keeps the two rules consistent and forecloses a future regression the way #42000 did for JSON.parse.Acceptance criteria
Number["parseInt"](x)(Literal property"parseInt") with missing radix, consistent with how the JSON rule now handlesJSON["parse"].parseIntaccessed via a global object identifier (globalThis/window/global), both dotted and computed, with missing radix.const p = parseInt; p(x),const { parseInt } = Number) explicitly out of scope, with a code comment matching the rationale already documented inrequire-json-parse-try-catch.ts(scope-analysis cost vs. risk).Scope
eslint-factory/**only.Filed by ESLint Refiner (daily run 2026-06-28).