Configuring ESLint Rules to Catch Bugs Before Runtime

Your Linter > Your Unit Tests

Why static analysis is the highest ROI testing you can do.

The Feedback Loop

• Unit Test — Write code -> Save -> Run Test Suite -> Wait -> Fail -> Fix.
• Linter — Type code -> Red Squiggly Line appears instantly.
• The Win — Catching a bug while typing is 100x cheaper than catching it in CI.

It's Not Just Formatting

Prettier handles style. ESLint handles logic.

• Floating Promises — Forgetting await on an async function. (Bug source #1).
• Deprecations — Preventing use of old APIs that you want to phase out.
• Complexity — Flagging functions that are too long or have too many loops.

Power Move: Custom Rules

• Context — You can write rules specific to your team's architecture.
• Example — "Imports from @server are forbidden in @client folders."
• Enforcement — Documentation gets ignored. Linter errors get fixed.

TypeScript Integration

• Strict Null Checks — Forces you to handle the case where data might be undefined.
• Unused Variables — Keeps the codebase clean and reduces cognitive load.

The 'Zero Config' Myth

• Don't settle — Default configs are too lenient. Turn on no-explicit-any.
• Consistency — The linter is the bad cop so you don't have to be in Code Reviews.

Summary: Automate Standards

Linting is automated mentorship.

If it can be caught by a rule, it shouldn't be a comment in a PR.

Is your linter set to 'Strict'?