Linting & Code Quality (ESLint, Prettier)
ESLint catches bugs and bad patterns; Prettier enforces consistent formatting automatically.
ESLint and Prettier solve two different problems and are meant to run together. ESLint is a static analysis tool: it inspects your code for likely bugs, anti-patterns, and rule violations (banning any, enforcing React hook dependency arrays, flagging stray console.log). Prettier is an opinionated code formatter: it reformats your source to a single canonical style (quotes, semicolons, line width, trailing commas) without judging correctness.
Because both tools historically had overlapping opinions about formatting, the convention is to let Prettier own all formatting and disable ESLint's stylistic rules. The prettier config in extends does exactly this — it turns off ESLint rules that would conflict with Prettier, which is why it must be listed last so it overrides everything before it.
A typical config layers shared presets via extends (eslint:recommended, the TypeScript plugin's recommended set, React and React Hooks recommended), then overrides specific rules. The .prettierrc is tiny by design — it only configures the handful of formatting choices Prettier exposes. Wire both into npm scripts (lint, lint:fix, format) so they run in CI and via pre-commit hooks.
The table below summarizes the division of responsibility:
| Tool | Job | Catches | Fix command |
|---|---|---|---|
| ESLint | Static analysis / linting | Likely bugs, anti-patterns, banned APIs | eslint --fix |
| Prettier | Code formatting | Inconsistent quotes, spacing, line width | prettier --write |
ESLint is your Java static analyzers — Checkstyle/PMD/SpotBugs/SonarLint — flagging code smells and likely bugs. Prettier is the auto-formatter, like `google-java-format` or Spotless: it rewrites your source to one canonical style so diffs stay clean and nobody argues about brace placement in code review.
- ESLint finds problems (bugs, bad patterns); Prettier fixes formatting. They are complementary, not competitors.
- The `prettier` entry in ESLint's `extends` must be last — it disables ESLint's formatting rules so the two tools don't fight.
- Wire `lint`, `lint:fix`, and `format` into package.json scripts and run them in CI / pre-commit hooks so style is enforced automatically, not by reviewers.
Worked Code
// .eslintrc.cjs
module.exports = {
root: true,
env: { browser: true, es2022: true },
extends: [
'eslint:recommended',
'plugin:@typescript-eslint/recommended',
'plugin:react/recommended',
'plugin:react-hooks/recommended',
'prettier', // must be last (disables formatting rules)
],
parser: '@typescript-eslint/parser',
plugins: ['@typescript-eslint', 'react'],
rules: {
'@typescript-eslint/no-explicit-any': 'error', // ban 'any'
'react-hooks/exhaustive-deps': 'error', // enforce deps
'no-console': 'warn',
},
};// .prettierrc
{
"semi": true,
"singleQuote": true,
"trailingComma": "all",
"tabWidth": 2,
"printWidth": 100
}// package.json scripts
"scripts": {
"lint": "eslint src/ --ext .ts,.tsx",
"lint:fix": "eslint src/ --ext .ts,.tsx --fix",
"format": "prettier --write src/"
}Interview-Ready Q&A
ESLint is a static analysis (linting) tool that catches likely bugs and bad patterns — banning any, enforcing exhaustive hook dependencies, flagging console.log. Prettier is an opinionated formatter that rewrites code to one canonical style (quotes, semicolons, line width). They are complementary: ESLint owns correctness/code quality, Prettier owns formatting. You run both, with Prettier handling all stylistic concerns.
- 1ESLint = catch bugs/anti-patterns; Prettier = enforce formatting. Use both.
- 2List 'prettier' last in extends so it disables conflicting ESLint formatting rules.
- 3Add lint / lint:fix / format scripts and run them in CI and pre-commit hooks.