Understanding JavaScript formatting
The shape of modern JavaScript.
Prettier picks every brace position, every line break, every quote style — so you don't have to argue about them.
The Prettier philosophy.
Prettier is opinionated. Where most older formatters give you knobs (where do braces go? semicolons or no? single or double quotes?), Prettier picks one answer for almost everything and sticks with it. The community accepted this trade because the cost of debating style outweighed the benefit of preferring a particular one.
Print width as the master rule.
The single most important Prettier setting is the print width — 80 characters by default. Code that fits on one line stays on one line; code that doesn't gets broken across multiple lines according to language-specific rules. Almost every formatting decision flows from "would this fit?" rather than from a separate config.
JavaScript or TypeScript — the parser auto-detects.
The formatter detects TypeScript from type annotations (: string, <T>, interfaces) and uses the TypeScript parser; otherwise it falls back to Babel for vanilla JavaScript. Both produce identical output for the JavaScript subset they share — the only difference is whether type syntax parses or errors.
Things Prettier won't fix.
A formatter is not a linter. Prettier won't catch unused variables, missing return statements, or assignment in a condition. It also won't change semantics — it never reorders statements, never collapses a redundant if, never inlines a constant. The output is guaranteed to be identical in behaviour to the input, just tidier.
JSX, async, decorators, the modern surface area.
JSX expressions, async/await, optional chaining, nullish coalescing, top-level await, decorators, private class fields — every modern syntax extension that Prettier's released parsers support is handled here. If a brand-new syntax (Stage-3 proposals) doesn't parse, that's a parser-version issue rather than a formatter design choice.