Don't Disable ESLint! Let's Keep It Clean

Every developer has faced this scenario: you’re working on a project, running ESLint, and suddenly… boom… a flood of warnings and errors! What do we do? 🤔

Some might say, “Let’s just disable it for now…” and add eslint-disable-next-line. But, hold on! Is that really the best way? 😅

Bypassing ESLint rules might feel like a quick fix, but it’s like sweeping the problem under the rug. So, how do we make sure that no one skips these important checks, and we keep the codebase clean and consistent? Let’s talk about forcing ESLint to play fair. 💪

🚀 How to Force ESLint and Avoid Sneaky Disables

You can enforce ESLint rules even when devs try to disable them inline. Here’s a way to make it impossible for anyone to use eslint-disable without your permission:

Add a custom rule in your .eslintrc file:

This rule will throw warnings when anyone tries to disable ESLint with comments like eslint-disable-next-line or eslint-disable:

// .eslintrc
"rules": {
  "no-warning-comments": [
    "warn",
    {
      "terms": ["eslint-disable-next-line", "eslint-disable"],
      "location": "anywhere"
    }
  ]
}

Set up pre-commit hooks:

You don’t want devs to bypass the linting process during commits, right? Here’s how you can ensure ESLint runs properly with a lint-staged hook in your package.json or .lintstagedrc:
```
// package.json or .lintstagedrc
"lint-staged": {
  "src/**/*.{js,jsx,ts,tsx}": [
    "bash ./check-eslint-disable.sh"
  ]
}
```

Create a script to detect disabled lines:

This little script will stop commits if any eslint-disable-next-line is found in the changed files:

// check-eslint-disable.sh
#!/bin/bash

# Check for eslint-disable-next-line in changed files
if git diff --cached --name-only | grep 'src/.*\\\\.[jt]sx*$' | xargs grep -R -n 'eslint-disable-next-line'; then
  echo "Found eslint-disable-next-line. The commit has been aborted."
  exit 1
else
  exit 0
fi

🔥 Why it Matters

Keeping ESLint active and non-bypassable ensures your code remains clean, readable, and consistent across the project. Let’s all agree: clean code = happy devs! ✨

So, let’s stop the “quick fixes” and get serious about writing great code! 💻✌️