[eli0shin]

ESLint returns exit code 1 for both real lint violations and configuration failures (e.g. parsing .md files not supported by the project's ESLint config). Previously the hook would block Claude on all exit code 1 cases, even for non-actionable errors like "Parsing error: ESLint was configured to run on .md".

Now when ESLint exits with code 1, the hook checks whether any errors appear at actual line numbers (>0). Configuration failures always appear at line 0:0 and are silently ignored. Only real code rule violations at non-zero lines block the agent.

Bumps plugin version from 1.0.2 to 1.0.3.

Fixes #54

Generated with Claude Code

[claude]

Code Review

Summary

This is a sensible fix for a real usability problem — ESLint's exit code 1 conflation between config errors and actual rule violations was causing unnecessary blocks. The approach is consistent with the existing pattern of string-matching guards already in the file.

---

Issues & Suggestions

1. Control flow clarity (minor)

The fall-through after the early output_json '{}' call works because output_json exits, but it reads a little oddly without an explicit else. Consider restructuring the block so the blocking path is inside an else branch rather than implicitly falling through. This makes the intent explicit and avoids relying on the implicit exit-via-helper to skip the remaining block.

2. Regex is coupled to ESLint's default text formatter

The pattern [1-9][0-9]*:[0-9]+[[:space:]]+(error|warning) works for ESLint's default stylish output, but will silently fail (and never block) if the project configures a different formatter (e.g. --format compact, checkstyle, etc.) since those use different line/column formats.

A more robust approach would be to force JSON output for the check and parse line > 0 programmatically using jq. That is a larger refactor, but the current approach is consistent with the existing string-matching guards in this file (lines 41-48), so it is acceptable for now — worth a follow-up issue.

3. Regex could match error descriptions, not just location markers

A message like Parsing error: expected '1:2 error' token in the output body could theoretically match the grep pattern. Very unlikely in practice, but an inherent risk of text parsing. The JSON formatter approach avoids this entirely.

4. Silent failure gives no feedback

When ignoring a config error, the hook returns {} with no output. If a user is confused why ESLint is not checking their .md files, there is no signal. A hookSpecificOutput with an additionalContext note (like the exit code 2 path on line 72) would help discoverability — though keeping it quiet to avoid noise is also a valid tradeoff.

5. No test coverage

The project has a test suite (bun test). It would be valuable to add tests for:

• Mock ESLint output containing only a 0:0 error → hook should NOT block
• Mock ESLint output with a 1:5 error → hook should block

---

Verdict

The fix correctly solves the reported issue (#54). The regex-based approach is pragmatic and consistent with the file's existing style. Main suggestions:

• Add an explicit else for clarity (easy win)
• Track a follow-up to migrate to --format json parsing for long-term robustness
• Add tests for the two new code paths

Good work identifying the root cause (exit code 1 is overloaded by ESLint) and explaining it clearly in the PR description.