Prettier is spreading through JavaScript projects rapidly. It's a code formatter that automatically formats your code and gives you almost no configuration options. This sounds terrible—who wants a tool that doesn't respect their preferences? But in practice, teams love it because it ends code style arguments forever.
What Prettier Does
Prettier takes your JavaScript (and CSS, HTML, Markdown, etc.) and rewrites it according to its own style rules. You save a file, Prettier reformats it. No arguments, no configuration, no debates.
// Before
function foo(x,y,z){return x+y+z;}
// After
function foo(x, y, z) {
return x + y + z;
}It handles:
- Indentation (2 spaces by default)
- Line length (wraps at 80 chars)
- Semicolons (adds them)
- Quotes (single by default)
- Trailing commas (adds them where valid)
The output is consistent, readable, and occasionally disagrees with your preferences.
The Philosophy: Opinionated and Automatic
Prettier's philosophy is radical: style preferences don't matter. What matters is consistency and automation.
The configuration options are minimal:
- Print width (default 80)
- Tab width (default 2)
- Semicolons (yes/no)
- Single quotes (yes/no)
- Trailing commas (yes/no/es5)
That's it. No indent style, no brace placement, no spacing rules. Prettier decides, you accept it.
This is liberating. You stop thinking about formatting and let the tool handle it.
Why Teams Adopt Prettier
The value proposition for teams is compelling:
Ends code review arguments – No more "can you add a space here" comments. Prettier enforces consistency automatically.
Onboarding is easier – New developers run Prettier and their code matches the team style immediately.
Cognitive load decreases – Don't think about formatting while writing code. Write messy code, save, it's formatted.
Git diffs improve – Code style changes don't pollute diffs. Only logic changes show up.
Works across editors – VS Code, Sublime, Vim, whatever. Everyone gets the same output.
The cost: giving up your preferred style. Most teams find this trade-off worth it.
Prettier + ESLint
Prettier handles formatting. ESLint handles linting (detecting bugs and bad patterns). They're complementary:
Prettier: formatting (spaces, semicolons, line breaks) ESLint: logic (unused variables, missing return, potential bugs)
Run both:
npm install --save-dev prettier eslint-config-prettiereslint-config-prettier disables ESLint's formatting rules that conflict with Prettier. ESLint focuses on code quality, Prettier handles style.
This combo is becoming the standard setup for JavaScript projects.
The Auto-Format Workflow
Integrate Prettier into your workflow:
On save – Editor plugins format when you save:
- VS Code: Prettier extension + "Format on Save"
- Sublime: JsPrettier plugin
- Vim: ale or prettier-vim
Pre-commit hook – Format before committing:
npm install --save-dev husky lint-staged{
"husky": {
"hooks": {
"pre-commit": "lint-staged"
}
},
"lint-staged": {
"*.js": ["prettier --write", "git add"]
}
}CI check – Fail builds if code isn't formatted:
prettier --check '**/*.js'The goal: developers never manually format code. It happens automatically.
What Prettier Gets Wrong (According to Some)
Prettier's opinionated nature means some developers hate the output:
Line wrapping – Prettier's algorithm for breaking lines doesn't match everyone's preferences. Sometimes it breaks lines you'd prefer on one line.
Ternaries – Prettier's ternary formatting is controversial:
const foo = condition
? longFunctionNameThatCausesWrapping()
: anotherLongFunctionName();Some developers prefer different ternary styles. Prettier doesn't care.
JSX – Prettier's JSX formatting sometimes produces awkward results with nested elements.
The philosophy: consistency matters more than aesthetics. If you can't get past this, Prettier isn't for you.
The Cultural Shift
Prettier represents a shift in how we think about code style:
Old way: Team debates style guide, documents it, enforces in code review. Style violations are human review burden.
Prettier way: Tool enforces style, no debate, no documentation needed. Humans review logic only.
This is similar to Go's gofmt and Rust's rustfmt. The programming language community provides a canonical formatter, everyone uses it.
JavaScript didn't have this. Now it does.
Adoption Challenges
Adopting Prettier in existing projects has friction:
The initial commit – Running Prettier on an existing codebase creates a massive commit touching thousands of lines. Git history looks ugly.
Solution: One big formatting commit, documented clearly. Git blame has --ignore-rev to skip formatting commits.
Team buy-in – Developers with strong style preferences resist giving up control.
Solution: Run a trial period. Most developers come around after using it for a week.
Legacy code – Old code formatted differently than new code looks inconsistent.
Solution: Format incrementally (files you touch) or do one big reformat.
Integration with Frameworks
Major frameworks are embracing Prettier:
Create React App – Includes Prettier formatting recommendations Vue CLI – Has Prettier option during project setup Angular CLI – Community plugins for Prettier integration
The ecosystem is moving toward Prettier as default.
The Bigger Picture
Prettier is part of a trend: automation over configuration. Developers want tools that just work, with minimal setup.
Compare:
- ESLint: Hundreds of rules to configure
- Prettier: Three meaningful options
ESLint's flexibility is sometimes necessary (project-specific rules). But for formatting, flexibility is a burden. Prettier's opinionated approach wins.
This pattern appears elsewhere:
- Create React App: Zero config build setup
- Next.js: Convention over configuration
- Parcel: Zero config bundler
The JavaScript ecosystem is maturing. We're learning that fewer choices can be better.
Should You Adopt Prettier?
For new projects: probably yes. Setup is trivial, benefits are immediate.
For existing projects: depends on team willingness to:
- Accept Prettier's style decisions
- Handle the big reformatting commit
- Configure editor integration
The ROI is highest for teams that:
- Spend time on code style in reviews
- Have inconsistent formatting across files
- Want to reduce onboarding friction
If you're a solo developer, Prettier is less compelling. The consistency benefits matter more for teams.
Practical Recommendations
To adopt Prettier successfully:
- Start with defaults – Don't overthink configuration
- Format everything at once – Rip off the band-aid
- Document the decision – Explain why to the team
- Configure editors – Make it automatic for everyone
- Add pre-commit hooks – Catch unformatted code before it's committed
- Update CI – Fail builds if code isn't formatted
The goal: developers never think about formatting again.
For setup guides, see the Prettier documentation and ESLint integration guide.
