JavaScript Formatter

Prettier is not merely inspired by this tool's formatting output — it is the literal Prettier package, downloaded and executed in your browser rather than through Node on a server, so the result is byte-identical to what running `npx prettier` locally would produce with the same configuration. That distinction matters because JavaScript formatting is genuinely hard to approximate: getting it right requires fully parsing the language, not pattern-matching against it, and a formatter that only approximates Prettier's behaviour will disagree with a project's actual Prettier config in exactly the edge cases where it matters — inside a decorator, a complex generic type, or an unusual JSX expression.

JavaScript contains several constructs that make a simple brace-and-semicolon-counting approach fail outright. Template literals can contain arbitrary text between backticks, including characters that look exactly like code — `` `function() { return "not real code"; }` `` is a single string value, not three statements, and a formatter that does not track template literal boundaries will misinterpret it. Regular expression literals are worse: `/{}/ ` contains characters that look like braces but are part of the regex pattern itself, not structural syntax. Automatic semicolon insertion adds a third layer of difficulty, since JavaScript allows omitting semicolons in many contexts and infers where a statement ends based on rules that a naive line-based formatter has no way to replicate correctly. Actually parsing the language into a proper syntax tree, the way Prettier does, is what avoids all three failure modes — a shortcut formatter that gets even one of them wrong on production code is a liability, not a convenience.

Prettier formats code — it standardises whitespace, line breaks, quote style and similar presentational choices — and explicitly does not check whether the code is correct, type-safe, or free of bugs. A file with a type error, an undefined variable reference, or a logical mistake formats without complaint as long as it is syntactically valid, because formatting and type-checking are separate concerns handled by separate tools. TypeScript's own compiler, or a linter like ESLint, is where correctness gets checked; this tool's job ends at making the code consistently and readably styled.

Tabs versus spaces, single quotes versus double, semicolons or not — none of these choices meaningfully affect how code runs, and disagreements over them used to consume real time in code review discussions that had nothing to do with correctness. Prettier's actual value proposition is removing that argument from the table entirely: a small, opinionated set of formatting rules applied automatically and identically everywhere means the debate is settled once, in configuration, rather than repeatedly in every pull request thereafter.

Every option exposed here — indentation width, semicolons, quote style — mirrors an actual Prettier configuration setting, so pasting code from a project with a known `.prettierrc` and matching those same settings here reproduces exactly what that project's own tooling would output, without needing to install anything locally just to check how a snippet would be formatted.