Prettier

What is Prettier?

Prettier is an opinionated code formatter. It parses your code into a syntax tree and reprints it with a deterministic layout, ignoring the whitespace you wrote. The output depends only on the code’s structure and a small set of options, so the same input always produces the same output.

That determinism is the point. Style arguments disappear because the formatter decides, not the team. Diffs shrink to actual changes instead of spacing churn, and reviewers spend their time on logic and design. Prettier is one of the few tools that measurably reduces friction in a codebase.

Configuration

Prettier works with no configuration, but you can set a few options in .prettierrc.

{
  "semi": true,
  "singleQuote": false,
  "trailingComma": "all",
  "printWidth": 100,
  "tabWidth": 2,
  "arrowParens": "always"
}

These are the options most teams touch. Beyond them, Prettier makes the decisions. The fewer options you set, the more consistent the result across projects and the less there is to maintain.

Running Prettier

Format files in place, or check without writing.

npx prettier --write .
npx prettier --check .
npx prettier --write src/app.tsx

--write reformats and saves; --check reports files that would change and exits non-zero, which is exactly what CI needs. Add a script so the commands are consistent.

{
  "scripts": {
    "format": "prettier --write .",
    "format:check": "prettier --check ."
  }
}

Ignoring files

.prettierignore lists paths to skip, using the same syntax as .gitignore.

dist
coverage
pnpm-lock.yaml
*.generated.ts

Ignoring build output and generated files matters: formatting them produces noise that the next build overwrites, and it can even break code generation that expects a specific layout.

Editor integration

Install the Prettier extension for your editor and enable format on save. This is where Prettier pays off most: you never think about formatting, and every save leaves the file clean. It also means you can use --check in CI with confidence, because formatting happens continuously rather than in a big cleanup at the end.

Working with ESLint

Prettier and ESLint overlap on style rules, and left alone they will fight. The standard solution is to let Prettier own formatting and disable the conflicting ESLint rules.

// eslint.config.js
import js from "@eslint/js";
import prettier from "eslint-config-prettier";

export default [js.configs.recommended, prettier];

eslint-config-prettier turns off every ESLint rule that would conflict with Prettier, so ESLint focuses on code quality and Prettier on layout. If you want formatting problems surfaced as lint errors, eslint-plugin-prettier runs Prettier as a rule, though many teams prefer to keep the two separate.

Pre-commit hooks

Formatting before a commit keeps CI green and history clean.

{
  "lint-staged": {
    "*.{js,jsx,ts,tsx,css,md}": "prettier --write"
  }
}

Combined with a hook runner such as husky, this formats only the staged files, so commits stay fast. It is a small amount of setup that prevents a whole class of “unformatted code” review comments.

Where Prettier fits

Prettier is formatting only. It does not find bugs, enforce types or check imports — those belong to ESLint and the type checker. A healthy toolchain runs all three: Prettier for layout, ESLint for quality and TypeScript for types. Each has one job, and none of them fights the others.

Best practices

• Accept the defaults unless your team has a strong reason to change one.
• Commit a .prettierrc so every editor and CI run agrees.
• Add .prettierignore for build output and generated files.
• Format on save in the editor.
• Run --check in CI and --write in a pre-commit hook.
• Disable conflicting ESLint rules with eslint-config-prettier.
• Keep the option list short.

Common mistakes

• Letting ESLint and Prettier both format and conflict.
• Formatting generated files and creating noisy diffs.
• Skipping the CI check, so unformatted code merges.
• Changing options per project for no reason and losing cross-project consistency.
• Running Prettier on the whole repo in a pre-commit hook and slowing commits.
• Using Prettier to enforce semantic rules that belong to ESLint.

Where to go next

Prettier removes a whole category of busywork. Pair it with ESLint for quality, TypeScript for type safety, and wire both into your Vite project and CI. Then set up format on save and never think about spacing again.