[eslint-refiner] ESLint Refiner — Daily Report 2026-07-24

[github-actions[bot]]

Overview

First run after a 16-day gap. The eslint-factory custom rule set grew substantially — 12 → 29 rules — so this run prioritized the newest, highest-impact rules (error-handling + command/route-injection security rules). Reviewed 7 of the 17 new rules; filed 2 non-duplicate issues (quality over cap).

Key metrics

Metric	Value
Rules in plugin	29 (was 12)
Rules reviewed ≥1×	18 / 29
New rules reviewed this run	7
Issues filed	2 (1 HIGH grounded, 1 MED soundness)
Prior findings confirmed FIXED	2

Issues filed

1. HIGH — no-err-stack-then-string-fallback misses the idiomatic instanceof Error guard (grounded, 3 live sites)

err instanceof Error ? err.stack : String(err) falls through both rules: no-err-stack-then-string-fallback only matches the && guard form, and prefer-get-error-message only matches a .message consequent (not .stack). The rule's own test file wrongly assumes the sibling covers this. Grounded at create_issue.cjs:1190 (where getErrorMessage() is already used one line above), copilot_sdk_driver.cjs:148, pi_agent_core_driver.cjs:393. The equivalent &&-guard sites are flagged today, so coverage shouldn't depend on guard style.

2. MED — no-child-process-interpolated-command doesn't resolve command-variable initializers (shell-injection FN)

The sibling no-exec-interpolated-command resolves an identifier command to its write-once initializer before classifying it; the child-process rule inspects only the syntactic first argument. So const cmd = \git ${x}`; execSync(cmd) escapes the **higher-severity** shell-injection guard. Ungrounded in the current (disciplined) corpus — filed as a soundness/consistency gap, matching the precedent of the previously-filed catch-less-try/finally` gap.

Confirmed fixed since last run (2026-07-08)

Two prior findings have landed

• Catch-less try/finally soundness gap — try-catch-rule-utils.isInsideTryBlock now requires ancestor.handler != null, so all sibling try/catch rules correctly no longer treat a try { ... } finally { } (no catch) as protective.
• require-fs-sync-try-catch destructured/bare-fs false negative — the new require-fs-io-try-catch uses createFsSyncMethodResolver(..., { allowUnboundFsIdentifier: true }), addressing the unbound-fs binding class.

Also reviewed (no new findings)

Three rules reviewed clean / guard-only

• no-github-request-interpolated-route — thorough Octokit-client detection + const-alias resolution + opaque-whole-route vs value-interpolation split. Zero interpolated .request() routes in the corpus (typed-placeholder discipline); acts as a regression guard.
• no-setfailed-then-exit-zero — thorough core.setFailed detection (direct/computed/alias/destructure) with forward-scan stopping at control transfer. No process.exit(0)-after-setFailed in the corpus.
• require-fs-io-try-catch — covers statSync/readdirSync/copyFileSync/unlinkSync/renameSync; live sites mostly wrapped.

Next actions

• 11 rules remain unreviewed — lead next runs with require-execsync/execfilesync/spawnsync/mkdirsync/new-url-try-catch, no-core-error-then-process-exit(code), no-throw-plain-object, require-return-after-core-setfailed, prefer-core-logging, no-core-exportvariable-non-string.
• Candidate grounded class: synchronous throwing fs methods covered by no rule (rmSync, openSync, chmodSync, realpathSync, symlinkSync, readlinkSync, truncateSync) — grep for unwrapped live sites before filing.
• Recurring indirection-FN theme: several rules inspect only the syntactic first argument (no variable resolution) while no-exec-interpolated-command resolves initializers — audit the interpolated-command / request-route rules for the same asymmetry.

Strategy and findings persisted to repo-memory (memory/eslint-refiner branch, 12 KB). Grounding is static (grep on non-test actions/setup/js/**/*.cjs); npm and live-lint are unavailable in this environment.

Generated by 🤖 ESLint Refiner · age00 · 370 AIC · ⌖ 13.4 AIC · ⊞ 3.8K · ◷

• expires on Jul 24, 2026, 10:18 PM UTC-08:00

[github-actions[bot]]

This discussion has been marked as outdated by ESLint Refiner.

A newer discussion is available at Discussion #47933.