What is it?
A linter (ESLint, Biome) finds bugs and bad patterns. A formatter
(Prettier, Biome) enforces consistent style. They run automatically on
save and on commit. Together they let humans review logic, not
indentation, semicolons, or let vs const.
Why it matters
Code review is your team's most expensive hour. Spending it on "missing
semicolon" is a tax on velocity. Linters catch real bugs (unused state,
exhaustive deps, unsafe any) and formatters end style debates. Teams
without them ship slower without knowing why.
What to learn
- ESLint: rules, configs, plugins, the flat config format
- Prettier: opinionated, almost zero options, just runs
- Biome — the all-in-one Rust replacement (faster, simpler config)
- Editor integration: format on save, lint as you type
- Pre-commit hooks: lint-staged + Husky, or simple-git-hooks
- Disabling rules:
eslint-disableetiquette and when it's actually right
Common pitfall
Disabling lint rules globally because they keep firing. Each rule fires for a reason — usually a real bug class. Take an hour to read what each rule catches before you turn it off. Most "annoying" rules are pointing at code that should change.
Resources
Primary (free):
- ESLint — Getting started · docs
- Prettier — What is it? · docs
- Biome — Migration guide · docs
Practice
Take any project and add ESLint + Prettier (or Biome). Configure them to
run on save in your editor, and add a pre-commit hook with lint-staged.
Push a deliberately ugly PR and watch CI catch it. Done when "format on
save" works in the editor and CI fails on style violations.
Outcomes
- Set up ESLint + Prettier on a fresh project in under 10 minutes.
- Read a lint error and fix the underlying issue (not just suppress it).
- Justify a rule disable with a comment, or refactor instead.
- Run lint + format in CI as a blocking step.