ESLint

ESLint enforces semantic and stylistic rules through AST-aware analysis. TypeScript projects add parser options and often type-aware rules from `typescript-eslint` for promises, imports, and unsafe `any` usage.

Modern configs use flat config (`eslint.config.js`) composing base, framework (React), and test overrides. Severity should match team tolerance: errors for correctness, warnings only when actionable.

					// eslint.config.js (sketch)
export default [
  { files: ['**/*.{ts,tsx}'], languageOptions: { parserOptions: { project: true } } },
  { rules: { 'no-unused-vars': 'error' } },
];
				

On interviews: flat vs legacy config, type-aware lint cost, plugin selection, CI `--max-warnings 0`, and safe auto-fix boundaries.

Common pitfalls: noisy rules teams ignore; running type-aware lint on entire monorepo without caching; duplicating Prettier concerns in ESLint.

The trade-off is bug prevention versus feedback latency and rule maintenance.

Checklist:

• Choose plugins aligned to stack (TS, React, a11y).
• Keep rules actionable.
• Run ESLint in CI with clear failure policy.
• Separate formatting from semantic lint.