[eslint-refiner] ESLint Factory Refinement Report — 2026-06-30

[github-actions[bot]]

Overview

Daily refinement pass over the four custom rules in eslint-factory (targets: actions/setup/js/**, 720 .cjs files). This run was a static review of rule sources and their test suites — the live npm run lint:setup-js pass could not run in this session (build/lint commands were blocked by sandbox approval), so findings come from reading the rule logic against the spec and the existing fixtures rather than fresh diagnostics.

Key metrics

Item	Value
Rules reviewed	4
New refinement tasks filed	3
Duplicates skipped	several (see below)
Severity mix	2 high, 1 medium

Refinement tasks filed

1. require-parseInt-radix accepts radix 0 / undefined (high, false negative). The arguments.length >= 2 short-circuit treats any second argument as a valid radix, but parseInt(x, 0) and parseInt(x, undefined) still trigger implicit base detection (0x → hex) — exactly what the rule targets. Also flags a broken autofix for spread calls (parseInt(...args) → parseInt(...args, 10)).
2. require-json-parse-try-catch autofix emits a useless catch (err) { throw err; } (high, weak autofix). The suggestion adds zero handling and is itself a no-useless-catch (eslint:recommended) violation — applying our fix trades one warning for another and teaches a no-op idiom.
3. no-unsafe-catch-error-property bare typeof err === 'object' guard is unsound (medium, false negative). typeof null === 'object', so the null-unchecked guard suppresses warnings on err.status where null.status would throw. Tighten to require a companion null check; mirror in the promise variant.

Duplicates / already-addressed items skipped

• eslint-factory: no-unsafe-catch-error-property guard is whole-block, causing branch-order false negatives #42189 — catch guard is whole-frame, causing branch-order false negatives. Still valid and open; not re-filed. (Task 3 is a distinct concern: the semantic strength of one guard form, not its placement.)
• eslint-factory: require-parseInt-radix misses computed/indirect parseInt access #42017 / eslint-factory: require-json-parse-try-catch misses indirect/computed JSON.parse access #41962 — aliased/destructured parseInt / JSON.parse callee tracking. Computed access is already implemented; aliased/destructured remains intentionally out of scope.
• eslint-factory: try-block ancestry check is unsound for deferred callbacks #41963 — deferred-callback try ancestry. Implemented in the current isDeferredCallback logic.
• eslint-factory: broaden no-unsafe-catch-error-property beyond message/stack/code to .status/.cause/.name #42188 / eslint-factory: no-unsafe-catch-error-property — add suggestions for stack/code and cover computed access #42190 — broaden catch props to .status/.cause/.name and add computed access + suggestions. Already present in the current rule (UNSAFE_PROPERTIES, computed-literal handling, wrapWithInstanceof suggestion).
• eslint-factory: add a test suite for require-parseInt-radix (currently zero coverage) #42015 / eslint-factory: add a suggestion fix + fix broken docs URL for require-parseInt-radix #42016 — require-parseInt-radix test suite and suggestion fix. Both present in current sources.

Continuity / repo-memory note

Repo-memory reads are sandbox-blocked this session (only writes succeed), so this run wrote a self-contained dated snapshot (state.json, findings-2026-06-30.json) rather than appending to prior history. If future runs also cannot read prior memory, the persistence pattern should move to dated, non-colliding snapshot files keyed by run date.

Next actions

• Implement the three filed tasks (each ships with concrete acceptance criteria and test deltas).
• Restore a live npm run lint:setup-js baseline in a future run to quantify real-world hit counts per rule and prioritize by violation volume.

References: §28425177261

Generated by 🤖 ESLint Refiner · 185.1 AIC · ⌖ 12.4 AIC · ⊞ 4.7K · ◷

• expires on Jun 30, 2026, 10:44 PM UTC-08:00

[github-actions[bot]]

This discussion has been marked as outdated by ESLint Refiner.

A newer discussion is available at Discussion #42683.