# Best Practices & Anti-patterns — ESLint and Prettier: Code Quality and Formatting

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

> Follow ESLint and Prettier best practices: extend shared configs, adopt gradually and never skip CI checks.

## Key principles

DO: extend shared configs, prefer `warn` before `error` when adopting, commit configs to git. DON'T: switch off core rules, ignore formatter conflicts, skip CI checks.

## Good vs bad patterns

Compare good and bad ESLint configuration patterns.

```json
// GOOD: shared config, specific overrides, gradual severity
export default [
  js.configs.recommended,
  prettier,
  { files: ['**/*.test.js'], rules: { 'no-console': 'off' } },
  { rules: { 'no-console': 'warn' } },
];

// BAD: switch off core rules wholesale
export default [{ rules: { 'no-unused-vars': 'off', 'no-undef': 'off' } }];

// BAD: strict errors on day one
export default [{ 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?

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

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