[eslint-refiner] ESLint Refiner — Daily Report 2026-07-12 #45052
Closed
Replies: 1 comment
-
|
This discussion has been marked as outdated by ESLint Refiner. A newer discussion is available at Discussion #45208. |
Beta Was this translation helpful? Give feedback.
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.
-
Overview
The
eslint-factoryrule set grew from 12 to 15 rules since the last run (2026-07-08). Three new rules landed as a batch:no-throw-plain-object,no-github-request-interpolated-route(already documented in the README), andrequire-return-after-core-setfailed(the 15th, undocumented). This run reviewed the two undocumented newcomers and filed 2 refinement issues (1 grounded HIGH, 1 latent MED).Key metrics
index.ts)require-return-after-core-setfailed,no-throw-plain-object)require-return: 0 (corpus disciplined) ·no-throw-plain-object: 22 grounded sitesIssues filed
no-throw-plain-object— add anObject.assign(new Error(...))suggestion (HIGH, grounded). The rule flagsthrow { ... }but ships no suggestion, even though its message prescribes the exact rewrite. It fires on 22 live production sites — JSON-RPC error objects ({ code, message, data }) inmcp_server_core.cjs(×10) andsafe_outputs_handlers.cjs(×12) — so automating the rewrite would make the rule actionable across a real, existing population. Recommended as an opt-in suggestion (not autofix) because some transport code mayJSON.stringifythe caught value.require-return-after-core-setfailed— aliased/destructuredcore.setFailedescapes detection (MED, latent). Detection is literal-only (core.setFailed), soconst { setFailed } = core; setFailed(msg)andconst c = core; c.setFailed(msg)are false negatives. Ungrounded today (the corpus is disciplined) but mirrors alias-blindspot fixes already made for sibling rules (fix(eslint): detect dropped await on local core.summary aliases #43404, eslint-factory: require-error-cause-in-rethrow's expressionReferencesCatchVar skips LogicalExpression/ConditionalExpression (idi [Content truncated due to length] #43948).Assessment of the newest rule
require-return-after-core-setfailedis robust and well-testedThe control-flow analysis handles same-block sequencing, cross-block continuation through
if/else/else if, loop back-edges (while/do/for/for-in/for-of), andswitchfall-through, and correctly stops at function boundaries. Traced true-negatives on the live corpus — all correct:check_permissions.cjs:45—setFailedlast in a terminalif-blockparse_threat_detection_results.cjs:477—setFailedterminal in anelse-block (setDetectionFailure)add_workflow_run_comment.cjs:165—setFailedlast inreportCommentErrorredact_secrets.cjs:281—setFailedlast in acatchEvery production
core.setFailed(...)is followed byreturnor is block/function-terminal → zero live violations. The rule mainly guards against regressions.Notes / not filed
arr.forEach(x => { if (bad) { core.setFailed(); } work(x); })— the rule flags and suggests insertingreturn;, butreturnin aforEachcallback only skips the current element; it does not stop the action. This is analogous to the rule's already-documentedbreak/continuelimitation and probably warrants a docs note rather than a code change.core.setFailed()— the rule intentionally treats loop re-iteration in a failed state as a violation (asserted by its tests).no-throw-plain-objectandrequire-return-after-core-setfailedare undocumented. Recommend a follow-up docs pass.Next actions
index.tsfor a possible 16th rule; otherwise giveno-github-request-interpolated-routeits first tracked review (grep interpolated.request(sites to ground).no-throw-plain-objectsuggestion lands, re-verify the rewrites against the MCP corpus for behavior preservation.References: §29182253758
Beta Was this translation helpful? Give feedback.
All reactions