# Best Practices और Anti-patterns — ESLint + Prettier

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

> जानें ESLint और Prettier के साथ क्या करें और क्या न करें।

## मुख्य सिद्धांत

करें: extends का उपयोग करें, initially error की जगह warn को prefer करें, configs को git में commit करें। न करें: सभी rules को disable करें, formatter conflicts को ignore करें, CI checks को skip करें।

## अच्छे vs बुरे patterns

Good और 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
```

## समय के साथ विकास

Loose (warn, कुछ rules) से शुरू करें और समय के साथ tighten करें (error, अधिक rules) जैसे टीम adapts। यह friction को कम करता है और adoption को improve करता है।

त्वरित जाँच

**Quiz:** टीम adoption के लिए एक best practice क्या है?

- [x] Warn के साथ शुरू करें, जैसे टीम adapts तो gradually error में move करें।
- [ ] सभी rules को immediately errors के रूप में लागू करें।
- [ ] अधिकांश rules को disable करें।

*Answer:* Warn के साथ शुरू करें, जैसे टीम adapts तो gradually error में move करें।. Gradual enforcement प्रतिरोध को कम करता है और टीम को progressively अपने workflow को adjust करने देता है।