# Prettier parses and reprints, and that is the whole contract

> Prettier is not a whitespace pass. It builds a syntax tree and prints it again under its own rules, which is why argument layout is not negotiable, why a prettier-ignore comment exists, and why the browser and Node builds are different files.

**prettier/prettier** — Prettier is an opinionated formatter that reprints JavaScript, TypeScript, CSS, HTML, Markdown, and more in one consistent style, and runs in editors, git hooks, or CI.

- Repository: https://github.com/prettier/prettier
- Website: https://prettier.io
- Stars: 52,319 · Forks: 5,021
- Language: JavaScript
- License: MIT
- Published: 2026-08-04 · Updated: 2026-08-18 · Language: en
- Canonical page: https://hysenlabs.com/projects/prettier-prettier

## A syntax tree goes in and a printed tree comes out

Prettier's contract is a full parse followed by a re-print, not a pass over whitespace. Code goes in, a syntax tree is built from it, and the tree comes back out under rules that take the maximum line length into account and wrap code when necessary. The README opens with the smallest useful case, a single call whose four arguments were typed on one line:
```
foo(reallyLongArg(), omgSoManyParameters(), IShouldRefactorThis(), isThereSeriouslyAnotherOne());
```
What comes back is not that line shortened or tidied, it is a re-print of the parse, which is why the result can differ from any layout a person would have picked by hand. The opinion in opinionated lives in this step, and it is also why a formatting diff can touch lines nobody edited by hand.

## prettier-ignore is the only way to keep your own layout

The output for that same call puts every argument on its own line and leaves a trailing comma:
```
foo(
  reallyLongArg(),
  omgSoManyParameters(),
  IShouldRefactorThis(),
  isThereSeriouslyAnotherOne(),
);
```
The input example is not merely long, it is preceded by a `<!-- prettier-ignore -->` comment, and that placement is the lesson. The marker tells the formatter to leave the next node alone, so the arguments stay on one line even though the printer would have wrapped them. This escape hatch is what makes an opinionated formatter workable, and it carries a cost worth naming: an ignored region is not formatted, but it is also not checked, so a block you mark once and keep editing can drift away from the style of the file around it.

## The package demands Node 22 and ships both module systems

The published package declares its floor in the engines field as node >=22, so the supported runtime is one fixed and fairly recent version rather than a range you can negotiate. Alongside that the manifest sets type to module, which makes the source ESM by default, and then hands out both shapes through the exports map. The main field still points at ./src/index.cjs as a CommonJS entry, the default condition points at ./src/index.js, and types resolves to ./src/index.d.ts. A project on an older Node cannot install its way around this, and a bundler that reads the main field receives the CommonJS build while a modern resolver receives the ESM one. Same package, two artifacts, and the difference stays invisible until something resolves the wrong condition.

## A browser bundler receives standalone.js instead of the main entry

There is a second entry point aimed at the browser, and it is not the same file the Node build uses. Both the browser field and the unpkg field point at ./standalone.js, and the exports map carries a ./standalone condition resolving to ./src/standalone.js. A bundler following the browser condition, or a script tag pulling from a CDN, therefore gets the standalone build, while the main and default conditions hand out index.cjs and index.js. The consequence is that two consumers of the same version can end up with different code and different behaviour, and the switch is silent rather than loud. The files list in the manifest ships index.js, standalone.js, src, and bin, which is why the standalone variant is present in the package at all instead of being produced at install time.

## The language list ends at YAML, and everything past it is a plugin

The header names the languages handled directly: JavaScript, TypeScript, Flow, JSX, and JSON on one line, then CSS, SCSS, and Less, then HTML, Vue, and Angular, then GraphQL, Markdown, and YAML. After that it asks for your favorite language and points at prettier.io/docs/plugins, which is the honest signal that the list is a boundary and not a promise. The parsers behind those languages sit in the manifest, among them @babel/parser, acorn and acorn-jsx, @typescript-eslint/typescript-estree, @glimmer/syntax, angular-estree-parser, and @bybrave/json5. Anything outside that set needs a plugin, and the exports map only opens ./plugins/* to ./src/plugins/*.js, so a plugin is reached by subpath rather than registered from the main entry.

## Editor, pre-commit hook, and CI are three different enforcement points

Prettier is described as running in three places. The first is your editor, on save, which keeps files formatted as they are written. The second is a pre-commit hook, which is where a repository turns the rule from advisory into enforceable. The third is a CI environment, and that entry links into the list-different section of the CLI documentation, which says the CI role is a check that reports rather than a rewrite. The split changes what a team feels. An on-save hook fixes the author, a pre-commit hook fixes the commit, and the CI check only tells you which commit to go back and fix, so a rule enforced only in CI produces red builds instead of clean diffs.

## The manifest reads 3.10.0-dev while the newest tag is 3.9.9

The version in package.json is 3.10.0-dev, and the tagged releases for the repository are 3.9.9, 3.9.8, and 3.9.7, most recent first. That gap is ordinary, but it decides what you get depending on where you install from and which branch you build. The tree also shows how the project is arranged: src/ for the implementation, with packages/, types/, bin/, and standalone.js at the edge; tests/ and benchmarks/ for verification and measurement; scripts/ and commands.md for tooling; website/ and docs/ for the published pages; and changelog_unreleased/ for work not yet tagged. Two separate ignore files, .prettierignore and .ignore, sit next to a prettier.config.js at the root, so the repository formats itself with the tool it ships.

## Conclusion

Prettier fits teams that want one enforced layout and are willing to stop arguing about whitespace. It does not fit codebases that need hand-tuned line breaks, and the prettier-ignore marker will be used more than you expect. Before adopting, check that your runtime is Node 22 or newer, decide deliberately whether you want the Node build or the standalone build, and read the language list in the header, because anything past YAML is a plugin you now depend on.

## FAQ

### how to use prettier

Prettier can be run in your editor on-save, in a pre-commit hook, or in a CI environment. It works by parsing your code and re-printing it with its own rules that take the maximum line length into account, wrapping code when necessary. Options, the CLI, and the API each have their own page under prettier.io/docs.

### how to install prettier

The repository gives no install command, it links to prettier.io/docs/install and to the prettier package on npm. The published package runs through the bin entry ./bin/prettier.cjs and requires Node 22 or newer, as declared in the engines field.

### how to use prettier in vscode

The repository points editors at prettier.io/docs/editors and says Prettier can be run in your editor on-save, but it does not document a specific VS Code extension, key binding, or editor configuration file. The repository tree does include a .vscode directory.

### What does Prettier mean?

The repository does not define the word or explain where the name came from. It describes the project only as an opinionated code formatter, and the header links out to documentation, install, options, the CLI, the API, and a playground.

### how to use prettier in intellij

The repository does not mention IntelliJ. Editor support is covered generically at prettier.io/docs/editors, and the route for a language outside the header list, which ends at GraphQL, Markdown, and YAML, is a plugin documented at prettier.io/docs/plugins.

## Sources

- [Official documentation](https://prettier.io)
- [Official README](https://github.com/prettier/prettier#readme)
- [Project repository](https://github.com/prettier/prettier)
- [Release notes](https://github.com/prettier/prettier/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/prettier-prettier