English for Prettier Developers
Vocabulary for developers configuring Prettier — opinionated formatting, format-on-save, and ESLint overlap — for teams discussing code style tooling in English.
Prettier disputes are rarely about Prettier itself — they’re about which decisions a team is willing to stop arguing about. Having the right vocabulary for “what Prettier controls” versus “what a linter controls” keeps those conversations short.
Formatting Basics
Opinionated formatter — a tool that reformats code according to a largely fixed set of rules, deliberately offering very few configuration options so teams stop debating style.
“Prettier is opinionated on purpose — the whole point is that we stop having tabs-vs-spaces arguments in code review.”
Idempotent formatting — running the formatter twice produces the same output as running it once; a correctly configured formatter should never keep changing the same code on repeated runs.
“If Prettier keeps re-formatting the same file on every commit, something’s not idempotent — check for a config conflict, not a Prettier bug.”
.prettierrc — the configuration file defining a project’s formatting options (line width, quote style, semicolons, etc.), checked into the repo so every contributor and CI run uses identical settings.
“Don’t rely on everyone’s editor defaults — commit a .prettierrc so CI and local formatting always agree.”
Workflow Integration
Format on save — an editor setting that runs Prettier automatically whenever a file is saved, so formatting is never a manual step or a PR review comment.
“Turn on format-on-save — that’s the whole reason ‘fix the formatting’ review comments should basically never happen anymore.”
Pre-commit hook — a Git hook that runs Prettier (often via a tool like lint-staged) before a commit completes, catching unformatted code before it ever reaches CI.
“Add a pre-commit hook so this gets caught locally instead of failing the format check in CI ten minutes later.”
Format check (CI) — a CI step that runs Prettier in “check” mode (no writes) and fails the build if any file isn’t already formatted, used as a gate rather than an auto-fixer.
“The format check failing isn’t a bug in your logic — it just means
npx prettier --writewasn’t run before you pushed.”
Prettier vs. Linters
Formatting vs. linting — formatting concerns whitespace, line breaks, and punctuation (Prettier’s job); linting concerns code correctness and patterns, like unused variables or missing dependencies (ESLint’s job).
“That’s not something Prettier should catch — an unused import is a linting concern, not a formatting one.”
Rule conflict (ESLint + Prettier) — when a linter’s stylistic rules disagree with Prettier’s output, usually resolved by disabling the linter’s stylistic rules and letting Prettier own formatting exclusively.
“Turn off ESLint’s indent rule — it’s fighting Prettier for control of the same thing, which is why the linter keeps flagging code Prettier just formatted.”
Common Mistakes
- Treating a Prettier disagreement as a linting bug report, when Prettier deliberately doesn’t expose the option being requested.
- Letting ESLint’s stylistic rules stay enabled alongside Prettier, causing the two tools to fight over the same lines.
- Skipping the pre-commit hook and relying only on CI, turning “run the formatter” into a slow feedback loop instead of an instant one.
Practice Exercise
- Explain, in two sentences, why Prettier is described as “opinionated” and why teams choose that on purpose.
- Write a short PR comment explaining that a failing CI format check just needs
prettier --write, not a logic change. - Draft a message recommending disabling an ESLint stylistic rule that conflicts with Prettier’s output.