[eslint-miner] eslint-factory: require-error-codes-in-safe-output-handler rule #63978

Summary

Adds a new custom ESLint rule, require-error-codes-in-safe-output-handler, to eslint-factory/src/rules, targeting a recurring gap in error-code standardization for actions/setup/js safe-output handler files.

Evidence: a recurring, unfixed conformance gap

scripts/check-safe-outputs-conformance.sh's USE-001 check has repeatedly flagged the same underlying finding — actions/setup/js/azure_devops_work_items.cjs throws errors without standardized ERR_*/E### codes — across issues #61738, #61965, #62136, #63370, #63572, and #63790. The file currently has 55 throw new Error(...) call sites and zero references to any error code.

Investigating why this keeps slipping through: the existing require-error-code-in-thrown-error rule only activates in files that already require("./error_codes.cjs"). Files like azure_devops_work_items.cjs, which never imported error_codes.cjs in the first place, are invisible to that rule — it returns a no-op for them. USE-001 is only caught by the bash conformance script (coarse, whole-file grep), which doesn't run as part of the normal ESLint feedback loop that contributors see while editing.

The new rule

require-error-codes-in-safe-output-handler flags .cjs files that:

1. Look like safe-output handlers — they contain octokit., safe_output/safeOutput, or NDJSON markers (mirroring the same heuristic used by check-safe-outputs-conformance.sh), and
2. Have 3 or more throw new Error(...) / core.setFailed(...) call sites, and
3. Contain zero references to a standardized error code (ERR_*, E###, or ERROR_*) anywhere in the file.

The 3+ threshold keeps false positives low: a handler that throws once or twice for an edge case unrelated to the error-code convention isn't flagged, avoiding noise on small utility files.

Validation

• cd eslint-factory && npm install && npm run build — clean, no errors.
• npx vitest run — all 67 test files / 687 tests pass, including 6 new tests for this rule (valid: no marker, valid: already coded, valid: below threshold; invalid: octokit-based, NDJSON-based, safe_output-based).
• npm run lint:setup-js — the rule fires exactly once, on azure_devops_work_items.cjs (55 uncoded throws), with zero false positives across the rest of the actions/setup/js/*.cjs corpus (82 total warnings, 0 errors — unchanged error count from baseline).
• README.md updated with a ### require-error-codes-in-safe-output-handler section documenting flagged/safe forms, keeping the README/index.ts rule-parity test green.

Files changed

• eslint-factory/src/rules/require-error-codes-in-safe-output-handler.ts (new rule)
• eslint-factory/src/rules/require-error-codes-in-safe-output-handler.test.ts (new tests)
• eslint-factory/src/index.ts (registration)
• eslint-factory/eslint.config.cjs (enable as "warn")
• eslint-factory/README.md (rule documentation)

No changes outside eslint-factory and actions/setup/js scope; no Go code touched.

Steering issue

The steering-issue reference in this run's context was blank/malformed, so no steer-keyword feedback could be looked up or incorporated.

To route changes like this to a review issue instead of blocking, configure protected-files: fallback-to-issue in your workflow configuration.

Generated by ESLint Miner · copilot · auto · 265.3 AIC · ⌖ 17.4 AIC · ⊞ 6.7K · ◷

• expires on Oct 5, 2026, 1:18 AM UTC-08:00