Prettier: Opinionated Code Formatter for JavaScript, TypeScript, CSS, and More

What Prettier Does and Who It Is For

Prettier solves the problem of inconsistent code style across a team or project by removing style decisions from the developer entirely. Rather than enforcing rules through a linter that reports violations, Prettier parses code and reprints it from scratch according to its own fixed rules. The README describes the core mechanism: it takes the maximum line length into account and wraps code when necessary.

The formatter is for any team or solo developer working in languages Prettier supports. The README names JavaScript, TypeScript, Flow, JSX, JSON, CSS, SCSS, Less, HTML, Vue, Angular, GraphQL, Markdown, and YAML as supported languages. A plugin system extends support to additional languages. The most common motivation is eliminating style arguments in code review by making formatting automatic and non-negotiable.

How Prettier Works: Parse, Transform, Print

Prettier's mechanism is print-based, not patch-based. When run on a file, it parses the source into an AST (Abstract Syntax Tree) using a language-specific parser, then reprints the AST into a new string using its own formatting rules. The original source layout is discarded entirely. This is different from tools that try to minimally modify existing code.

The README illustrates this with a JavaScript example. Input:

foo(reallyLongArg(), omgSoManyParameters(), IShouldRefactorThis(), isThereSeriouslyAnotherOne());

Output:

foo(
  reallyLongArg(),
  omgSoManyParameters(),
  IShouldRefactorThis(),
  isThereSeriouslyAnotherOne(),
);

Prettier broke the call into multiple lines because the single-line form exceeded the configured print width. This print-width rule applies consistently across all supported syntax constructs. The `package.json` shows that Prettier uses separate parser packages for each supported language: `@babel/parser` for JavaScript, `@typescript-eslint/typescript-estree` for TypeScript, `@angular/compiler` for Angular templates, and others.

Installing Prettier and Running It in VS Code

The documentation at prettier.io/docs/install covers the full installation. Prettier ships as the `prettier` npm package, listed in the repository's own `package.json`. The `package.json` shows the engines field requires Node.js 22 or later.

For editor integration, the README points to prettier.io/docs/editors. In VS Code, the recommended path is installing the Prettier extension and setting format-on-save. The `prettier.config.js` at the root of the repository is the configuration file format; a `.prettierignore` file (also present in the root) excludes files and directories.

Prettier can also run in CI using the `--list-different` flag, which exits with a non-zero status when any file does not match Prettier's output. The README describes this as a way to ensure consistent style without requiring developers to post formatting comments on code review. Pre-commit hook integration is documented at prettier.io/docs/precommit.

Configuration: What You Can and Cannot Change

Prettier is intentionally limited in configuration options. The documentation at prettier.io/docs/options describes the available settings: print width (default 80), tab width, whether to use tabs or spaces, semicolons, single or double quotes, trailing commas, bracket spacing, bracket same-line, single attribute per line, prose wrap for Markdown, end of line, and a few others.

The word "opinionated" in Prettier's description reflects a deliberate design decision: the fewer options available, the fewer decisions teams need to make. Many formatting choices that developers argue about (brace style, operator placement, line break positions) are simply not configurable. The output is always what Prettier decides it should be.

For languages or formatting patterns not covered by the built-in rules, a plugin system exists. The documentation at prettier.io/docs/plugins lists both official and community plugins. The `@prettier/cli` package listed in `package.json` is a separate CLI interface.

Limitations and Where Prettier Is the Wrong Tool

Prettier formats code; it does not enforce code quality. It does not catch bugs, unused variables, undeclared functions, or logic errors. It is typically used alongside a linter such as ESLint, not instead of one. The two tools can produce conflicts if both enforce rules about the same syntax (for example, both trying to manage spacing), which requires disabling the relevant ESLint style rules when Prettier is in use.

The parse-and-reprint approach means that Prettier rewrites the entire file every time it runs, even if only one character changed. Diff output in version control becomes larger because entire blocks are reformatted. Teams that have a large existing codebase will produce a one-time large reformatting commit when adopting Prettier, which can complicate `git blame` for the affected code.

Prettier does not support all languages. Some languages commonly used in web development (PHP, Python, Java, SQL) are handled only through community plugins rather than built-in support, and plugin quality varies.

The `package.json` shows Node.js 22 as the minimum engine version, which is a constraint for environments running older Node.js versions.

Comparing Prettier to ESLint and dprint

ESLint is a linter for JavaScript and TypeScript that can also enforce style rules through its `--fix` flag. When ESLint's `stylistic` rules are enabled, it partially overlaps with Prettier. The conventional recommendation is to use Prettier for formatting and ESLint for code quality, disabling ESLint's style rules to avoid conflicts. The `eslint-config-prettier` package handles that conflict removal.

dprint is a code formatting tool written in Rust that supports JavaScript, TypeScript, JSON, Markdown, and other formats through plugins. It uses a plugin architecture and is generally faster than Prettier on large codebases due to Rust's performance characteristics. Unlike Prettier, dprint offers more configuration surface. Teams that find Prettier's minimal configuration too restrictive, or who need faster formatting in CI, sometimes move to dprint.

Maintenance and Licence

The repository is not archived. The last push was on 2026-09-24. The most recent release is 3.9.9 from 2026-09-23, with 3.9.8 and 3.9.7 released days earlier in September, indicating a fast patch cadence. The `package.json` shows an in-development version 3.10.0-dev on the main branch.

Prettier is MIT licensed, which is permissive and places no restrictions on use in proprietary software. The repository is funded through GitHub Sponsors as shown in the FUNDING.json file. Upgrades between patch versions of Prettier can occasionally change formatting output even without option changes, because parser or print rule improvements alter how some constructs are reprinted. Teams that rely on deterministic formatting output should pin the Prettier version in their `package.json` dependencies.

Editorial conclusion

Prettier is the right tool for any JavaScript, TypeScript, or CSS project where consistent formatting is the goal and the team is willing to accept its limited configuration surface. It integrates with VS Code, pre-commit hooks, and CI with minimal setup. It is not a linter and should be used alongside ESLint for code quality. Teams running Node.js versions below 22 need to check compatibility before upgrading to recent Prettier releases.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes