[eslint-refiner] ESLint Refiner Daily Report - 2026-08-19 #53916
Closed
Replies: 1 comment
|
This discussion was automatically closed because it expired on 2026-08-20T05:32:31.761Z.
|
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
ESLint Refiner — Daily Report (2026-08-19)
Scope:
eslint-factory/**custom rules targetingactions/setup/js/**.This run followed a 6-week gap since the last recorded run (2026-07-08). In that time the rule inventory grew from 12 to 51 rules, and
ghsearch revealed the two/three rules reviewed today had already been through 15+ prior refinement rounds not reflected in this workflow's persisted memory — a reminder that repo-memory history is a lower bound on prior work, not the full record. All previously-open issues tracked in memory (9 total, from 2026-06-27 through 2026-07-08) are now closed/fixed.Key metrics
gh api search/issues)Strategy shift
The repo is a shallow git clone (1 commit visible), so the old "diff
index.tsimports to find the newest rule" heuristic is dead — there's no date signal to rank by. This run switched to severity-based prioritization: review unreviewed rules that guard against injection/RCE-class defects first. That pointed at the three sibling rules sharingcommand-initializer-utils.ts:no-child-process-interpolated-command,no-exec-interpolated-command, andno-github-request-interpolated-route.Issues filed
resolveInitializermishandles destructured bindings (high severity, cross-rule) — the shared initializer-resolution helper incommand-initializer-utils.tsreturns the whole right-hand-side expression forconst [x] = arr/const {x} = objbindings instead of treating them as unresolved, same class of bug the siblingisChildProcessObjectBindinghelper already guards against elsewhere in the same rule family. A single fix corrects all three consuming rules. Grounded: the exact destructure-into-exec-arg shape already exists live increate_labels.cjs:46.no-exec-interpolated-commandhas zero coverage for theexecApiparameter-alias pattern (medium-high severity) — the rule only matches the literal identifierexec, but the dominant calling convention in the two largest git-mutation scripts (git_helpers.cjs, 20+ sites;create_pull_request.cjs, 15+ sites) isexecApi.exec(...)/execApi.getExecOutput(...), which the rule never sees. Proposed a narrow, disambiguated fix (array-as-2nd-arg heuristic) that won't collide withRegExp.prototype.exec(str).Grounding detail and true negatives
create_labels.cjs:46:const [bin, ...prefixArgs] = cmdPrefixStr.split(" ").filter(Boolean);feedingexec.getExecOutput(bin, ...)— currently benign (env-derived prefix) but exercises the exact defect mechanism live.git_helpers.cjs/create_pull_request.cjs: 35+ combinedexecApi.exec()/execApi.getExecOutput()call sites, all currently passing static"git"commands — no live true-positive missed today, but zero rule coverage on these files going forward.add_reaction.cjs,add_workflow_run_comment.cjs(unresolvable by design, correctly unflagged); ternary-computed static routes inupdate_project.cjs:930andcreate_project.cjs:230(both branches static literals, correctly unflagged).ConditionalExpression/ternary branches are never unwrapped byisStaticExpression/isStaticRouteExpressionin either the shared util or the route rule. No live instance has a dynamic ternary branch today, so this stays a watch-item rather than a filed issue.Next actions
no-caught-error-interpolation,require-escaped-regexp-interpolation,require-execsync-try-catch/require-execfilesync-try-catch,require-spawnsync-error-check/require-spawn-error-listenerare next in line (36 of 51 rules remain unreviewed at least once).gh search/issuesbefore filing — this run found the memory's issue-tracking undercounted prior work by 15+ issues.ConditionalExpressionranking gap.Repo-memory updated and validated (4.7 KB patch, well under the 12 KB limit).
All reactions