Prettier and Opinionated Code Formatting with James Long

March 19, 2026

50 min episode · 2 min read

James Long

Episode

50 min

Read time

2 min

AI-Generated Summary

Published Mar 19, 2026

Key Takeaways

✓Opinionated formatting over configurable rules: ESLint's 100+ formatting rules still left room for team disagreement and couldn't handle dynamic JavaScript patterns like inline callback arguments. Prettier eliminates debate by accepting only one meaningful parameter — print width — and producing identical output regardless of how the original code was written, removing style decisions entirely from code review.
✓Prettier ignore as the escape valve: When teams resist adopting Prettier due to intentional formatting choices — such as aligned equals signs in enums — the practical response is to use `// prettier-ignore` comments above those specific blocks. Long estimates only 0.1% of a typical codebase genuinely warrants manual formatting exceptions, making blanket resistance to automation statistically unjustified.
✓Never run Prettier through ESLint: Using the ESLint-Prettier plugin routes formatting through ESLint's rule engine, which reruns fixers up to 10 times when fixes conflict, turning a sub-second formatting operation into a multi-second delay per save. Running Prettier directly as a separate process avoids this overhead entirely and keeps the two tools' responsibilities cleanly separated.
✓Unified AST toolchains solve the real performance problem: Tools like Biome and OXC format are faster not solely because they use Rust, but because they parse JavaScript once and pass a single AST through formatting, linting, and analysis sequentially. The traditional stack parses and regenerates code at each tool boundary, multiplying overhead — a structural inefficiency that a Rust rewrite alone would not fix.
✓Open source financial sustainability gap: Prettier has raised approximately $243,000 total across nine-plus years on OpenCollective, with no full-time maintainers and no backing company. Long frames this as the standard open source trajectory: initial creative energy drives adoption, but long-term maintenance requires compensation structures that donation models rarely provide at sufficient scale for tools used by millions of developers daily.

What It Covers

James Long, creator of Prettier, joins Josh Goldberg on Software Engineering Daily to discuss how the opinionated JavaScript formatter emerged from code-style debates at Mozilla, why deterministic formatting removes team friction, the technical complexity of building formatters, and the financial realities of sustaining popular open source tooling.

Key Questions Answered

•Opinionated formatting over configurable rules: ESLint's 100+ formatting rules still left room for team disagreement and couldn't handle dynamic JavaScript patterns like inline callback arguments. Prettier eliminates debate by accepting only one meaningful parameter — print width — and producing identical output regardless of how the original code was written, removing style decisions entirely from code review.
•Prettier ignore as the escape valve: When teams resist adopting Prettier due to intentional formatting choices — such as aligned equals signs in enums — the practical response is to use `// prettier-ignore` comments above those specific blocks. Long estimates only 0.1% of a typical codebase genuinely warrants manual formatting exceptions, making blanket resistance to automation statistically unjustified.
•Never run Prettier through ESLint: Using the ESLint-Prettier plugin routes formatting through ESLint's rule engine, which reruns fixers up to 10 times when fixes conflict, turning a sub-second formatting operation into a multi-second delay per save. Running Prettier directly as a separate process avoids this overhead entirely and keeps the two tools' responsibilities cleanly separated.
•Unified AST toolchains solve the real performance problem: Tools like Biome and OXC format are faster not solely because they use Rust, but because they parse JavaScript once and pass a single AST through formatting, linting, and analysis sequentially. The traditional stack parses and regenerates code at each tool boundary, multiplying overhead — a structural inefficiency that a Rust rewrite alone would not fix.
•Open source financial sustainability gap: Prettier has raised approximately $243,000 total across nine-plus years on OpenCollective, with no full-time maintainers and no backing company. Long frames this as the standard open source trajectory: initial creative energy drives adoption, but long-term maintenance requires compensation structures that donation models rarely provide at sufficient scale for tools used by millions of developers daily.

Notable Moment

Long revealed that the productivity benefit Prettier became most known for — writing messy code and reformatting it instantly with one keystroke — was never the original design goal. He built it to eliminate PR review arguments, and the authoring speed improvement emerged as an entirely unplanned side effect after release.

Know someone who'd find this useful?