# Best Practices & Anti-patterns — ESLint + Prettier

Source: https://www.geekswithgeeks.com/en/eslint-prettier/eslint-prettier-21

> Learn what to do and what not to do with ESLint and Prettier.

## Key principles

DO: Use extends, prefer warn over error initially, commit configs to git. DON'T: Disable all rules, ignore formatter conflicts, skip CI checks.

## Good vs bad patterns

Compare good and bad ESLint configuration patterns.

```json
// GOOD: Use extends and overrides
{ "extends": ["eslint:recommended", "prettier"],
  "overrides": [{ "files": "*.test.js", "rules": { "no-console": "off" } }]
}

// BAD: Disable everything, no extends
{ "rules": { "no-unused-vars": "off", "no-undef": "off" } }

// GOOD: Gradual enforcement
{ "rules": { "no-console": "warn" } }

// BAD: Immediate strict errors on adoption
{ "rules": { "no-console": "error" } }
```

Output:

```
Good patterns use extends, overrides, and warn initially
```

## Evolution over time

Start loose (warn, few rules) and tighten over time (error, more rules) as the team adapts. This reduces friction and improves adoption.

Quick check

**Quiz:** What's a best practice for team adoption?

- [x] Start with warn, gradually move to error as team adapts.
- [ ] Enforce all rules as errors immediately.
- [ ] Disable most rules.

*Answer:* Start with warn, gradually move to error as team adapts.. Gradual enforcement reduces resistance and allows the team to adjust their workflow progressively.