Rule
eslint-factory/src/rules/require-mkdirsync-try-catch.ts
Problem (consistency / false-negative)
The two sibling fs-sync rules configure the shared resolver differently:
// require-fs-sync-try-catch.ts:32
const resolveFsSyncMethod = createFsSyncMethodResolver(sourceCode, FS_SYNC_METHODS, { allowUnboundFsIdentifier: true });
// require-mkdirsync-try-catch.ts:28
const resolveFsSyncMethod = createFsSyncMethodResolver(sourceCode, FS_SYNC_METHODS);In try-catch-rule-utils.ts:222-223, allowUnboundFsIdentifier lets the resolver match fs.<method>(...) when the receiver is literally named fs even if fs cannot be resolved to a local require('fs')/import binding:
const canUseUnboundFsIdentifier = options.allowUnboundFsIdentifier === true && callee.object.name === "fs";
if (!canUseUnboundFsIdentifier && !isIdentifierBoundToFsModule(callee.object.name, callee.object)) return null;
So require-fs-sync-try-catch flags an unwrapped fs.readFileSync(p) even when the fs binding isn't visible, but require-mkdirsync-try-catch silently ignores the analogous unwrapped fs.mkdirSync(dir, { recursive: true }). Same receiver, same protective intent, different behavior.
Grounding
Ungrounded in the current corpus: every non-test .cjs mkdirSync site binds const fs = require("fs") locally and is already wrapped in try/catch, and setupGlobals does not inject a global fs. This is a latent inconsistency/robustness gap, not a live miss — but it makes the mkdir rule strictly weaker than its sibling for no stated reason.
Why tests don't catch it
The rule's "non-fs objects" valid tests only use differently-named receivers (mockFs, storage, myObj); there is no test for an unresolved receiver literally named fs, so the divergence from the sibling rule is untested.
Acceptance criteria
Filed by ESLint Refiner (daily rule-refinement pass). Verified against rule sources + shared resolver.
Generated by 🤖 ESLint Refiner · 786.5 AIC · ⌖ 10.8 AIC · ⊞ 4.6K · ◷
Rule
eslint-factory/src/rules/require-mkdirsync-try-catch.tsProblem (consistency / false-negative)
The two sibling fs-sync rules configure the shared resolver differently:
In
try-catch-rule-utils.ts:222-223,allowUnboundFsIdentifierlets the resolver matchfs.<method>(...)when the receiver is literally namedfseven iffscannot be resolved to a localrequire('fs')/import binding:So
require-fs-sync-try-catchflags an unwrappedfs.readFileSync(p)even when thefsbinding isn't visible, butrequire-mkdirsync-try-catchsilently ignores the analogous unwrappedfs.mkdirSync(dir, { recursive: true }). Same receiver, same protective intent, different behavior.Grounding
Ungrounded in the current corpus: every non-test
.cjsmkdirSyncsite bindsconst fs = require("fs")locally and is already wrapped in try/catch, andsetupGlobalsdoes not inject a globalfs. This is a latent inconsistency/robustness gap, not a live miss — but it makes the mkdir rule strictly weaker than its sibling for no stated reason.Why tests don't catch it
The rule's "non-fs objects" valid tests only use differently-named receivers (
mockFs,storage,myObj); there is no test for an unresolved receiver literally namedfs, so the divergence from the sibling rule is untested.Acceptance criteria
require-mkdirsync-try-catch.ts:28tocreateFsSyncMethodResolver(sourceCode, FS_SYNC_METHODS, { allowUnboundFsIdentifier: true }).fs.mkdirSync(dir, { recursive: true });with nofsbinding in scope →missingTryCatch.mockFs/storage/myObjcases stay valid (unaffected —allowUnboundFsIdentifieronly relaxes for receiver namefs).Filed by ESLint Refiner (daily rule-refinement pass). Verified against rule sources + shared resolver.