English for Prettier Developers

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 --write wasn’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

1. Explain, in two sentences, why Prettier is described as “opinionated” and why teams choose that on purpose.
2. Write a short PR comment explaining that a failing CI format check just needs prettier --write, not a logic change.
3. Draft a message recommending disabling an ESLint stylistic rule that conflicts with Prettier’s output.

Related Resources

• English for Biome Linter Developers
• English for Vitest Developers
• English for GitLab CI Developers

Navigating the Nuances: Beyond “Fix This” Comments

The core of effective communication around tools like Prettier lies not just in knowing what to do – configuring settings, running commands – but how to articulate those decisions and, crucially, understand feedback. Many non-native English speakers find the directness of technical discussions challenging, particularly when encountering phrasing like “fix this” or overly prescriptive comments. These can feel judgmental and immediately defensive. The key is to frame your responses in terms of shared goals – maintaining consistency across a project – rather than personal correction. It’s about building a collaborative understanding, not dictating rules.

A common scenario arises during code reviews when a developer notices a Prettier formatting difference from their preferred style. Instead of simply stating “This violates Prettier,” a more constructive approach is to explain the reasoning behind the change. For example, responding to a comment like “Format this” with “I’ve applied Prettier to ensure consistent spacing around operators for improved readability – it’s a common practice in our team.” This immediately shifts the focus from personal preference to established best practices. Similarly, when describing changes in a Pull Request, stating “Applying Prettier to enforce consistent indentation and line length as per team guidelines” is far more effective than simply “Prettier formatting applied”. Another frequent issue arises when format-on-save isn’t working correctly, leading to frustrating conflicts between Prettier and ESLint. A helpful Slack message might be: “Hey team, I’m encountering some intermittent issues with Prettier’s format-on-save. It seems to be conflicting with ESLint in certain scenarios – could we discuss potential configuration adjustments or temporary workarounds?” Remember, even a simple acknowledgement of the problem and an invitation for collaboration can de-escalate tension.

Furthermore, understanding technical terminology is crucial. “Opinionated” isn’t just a word; it describes Prettier’s proactive approach to formatting, setting rules rather than relying solely on developer discretion. Mastering phrases like “enforce style guidelines” or “maintain consistent formatting” demonstrates a deeper comprehension of the tool’s purpose and value. Don’t shy away from explaining why you’re using a specific Prettier configuration; it fosters trust and shows commitment to team standards.

# Example: Using Prettier to format a single file
prettier --write my-file.js

This simple command demonstrates the core functionality – automatically applying Prettier’s rules. Focusing on such concrete examples when explaining your actions can help bridge communication gaps and build confidence in your understanding. Remember, clear communication builds stronger teams.