Why is Prettier rock solid?

Prettier, the popular JavaScript/TypeScript code formatter, is praised for its reliability and the way it standardizes style across teams, reducing bikeshedding over formatting and making code reviews easier. Commenters trace its robustness to a mix of solid underlying algorithms, extensive test coverage, and corporate backing, but they also highlight real drawbacks: performance issues compared to newer Rust-based tools, breaking changes or edge-case bugs (especially in HTML and template languages), and limited configurability that can frustrate users. The debate broadens into whether strict, opinionated autoformatters are a net benefit for developer practice and team collaboration, or whether they encourage overreliance and unnecessary complexity.

Why Prettier Is Seen as “Rock Solid”

  • Many attribute its robustness less to a single clever algorithm and more to extensive tests, lots of edge‑case labor, and long-term maintenance.
  • A recurring theme: corporate backing (Meta) and a staffed maintainer team make reliability and continuity much more likely than for volunteer-only projects.
  • Some argue its real value is in teams: it removes formatting bikeshedding from code review and ensures consistent diffs.

Algorithms, IRs, and Line Breaking

  • Discussion contrasts functional “pretty printing languages” (Wadler-style) with more ad‑hoc / search-based formatters (clang-format, YAPF, dartfmt).
  • Line splitting is repeatedly called “the hard part”; gofmt’s avoidance of complex wrapping is cited as a big simplification.
  • One formatter author explains rewriting their IR because indentation and line breaks interact in non-local, combinatorial ways.
  • There’s debate whether functional PPL-style approaches are expressive enough for real-world, complex languages.

Bugs, Breakages, and Issue Counts

  • Several concrete Prettier bugs are cited: breaking XHTML DOCTYPE, moving TypeScript ignore comments, mangling nested CSS functions, problems with Django HTML and Astro, and long-standing issues.
  • 1k+ open issues are interpreted by some as evidence of complexity or language ecosystem “crappiness”; others see it as normal for widely used tools.
  • Prettier has shipped behavior-changing formatting in patch releases (e.g., around JSONC/tsconfig), leading to debate over what counts as a “breaking change” and how strictly semantic versioning should be followed.

Performance and Alternatives

  • Complaints that Prettier is noticeably slower than tools like ocamlformat, ruff, and Rust-based Biome; some users switch primarily for speed.
  • Dprint, Biome, golines, and various linters/formatters (Black, isort, reorder-python-imports, ESLint Stylistic, standardjs) are mentioned as alternatives or complements.

Philosophy of Formatting

  • Some see autoformatting as essential and freeing; code is written in a loose “shorthand” and cleaned on save.
  • Others find Prettier mediocre, overhyped, or too opinionated, and argue formatting is overrated relative to logic.
  • There’s tension between strict, non-configurable tools (Black, Prettier defaults) and teams wanting more control over style and diffs.
  • A few worry that heavy reliance on formatters harms junior developers’ sense of code aesthetics; others consider that a low‑value skill compared to higher‑level competencies.