Por que o Prettier é tão sólido?
O Prettier, o popular formatador de código para JavaScript/TypeScript, é elogiado por sua confiabilidade e pela forma como padroniza o estilo entre equipes, reduzindo discussões improdutivas sobre formatação e facilitando revisões de código. Os comentaristas atribuem sua robustez a uma combinação de bons algoritmos subjacentes, cobertura extensa de testes e apoio corporativo, mas também destacam desvantagens reais: problemas de desempenho em comparação com ferramentas mais novas baseadas em Rust, mudanças que quebram compatibilidade ou bugs em casos de borda (especialmente em HTML e linguagens de template) e configurabilidade limitada, que pode frustrar usuários. O debate se amplia para saber se autoformatadores estritos e opinativos são, no fim das contas, benéficos para a prática de desenvolvimento e a colaboração em equipe, ou se incentivam dependência excessiva e complexidade desnecessária.
Por que o Prettier é visto como “à prova de falhas”
- Muitos atribuem sua robustez menos a um único algoritmo brilhante e mais a testes extensivos, muito trabalho em casos de borda e manutenção de longo prazo.
- Um tema recorrente: o apoio corporativo (Meta) e uma equipe de mantenedores remunerados tornam a confiabilidade e a continuidade muito mais prováveis do que em projetos apenas de voluntários.
- Alguns argumentam que seu valor real está nas equipes: ele elimina discussões improdutivas sobre formatação na revisão de código e garante diffs consistentes.
Algoritmos, IRs e quebra de linha
- A discussão contrasta linguagens funcionais de “pretty printing” (no estilo de Wadler) com formatadores mais ad hoc / baseados em busca (clang-format, YAPF, dartfmt).
- A divisão de linhas é repetidamente chamada de “a parte difícil”; a forma como o gofmt evita wrap complexo é citada como uma grande simplificação.
- Um autor de formatador explica que reescreveu seu IR porque indentação e quebras de linha interagem de maneira não local e combinatória.
- Há debate sobre se abordagens funcionais no estilo PPL são expressivas o suficiente para linguagens reais e complexas.
Bugs, quebras e contagem de issues
- Vários bugs concretos do Prettier são citados: quebra do XHTML DOCTYPE, movimentação de comentários ignore do TypeScript, corrupção de funções CSS aninhadas, problemas com HTML do Django e Astro, e issues de longa data.
- Mais de 1 mil issues abertas são interpretadas por alguns como evidência de complexidade ou da “ruindade” do ecossistema de linguagens; outros veem isso como algo normal para ferramentas amplamente usadas.
- O Prettier já lançou formatação com mudança de comportamento em releases de patch (por exemplo, em torno de JSONC/tsconfig), o que gerou debate sobre o que conta como uma “breaking change” e quão estritamente o versionamento semântico deve ser seguido.
Desempenho e alternativas
- Há reclamações de que o Prettier é visivelmente mais lento do que ferramentas como ocamlformat, ruff e Biome baseado em Rust; alguns usuários trocam principalmente por velocidade.
- Dprint, Biome, golines e vários linters/formatadores (Black, isort, reorder-python-imports, ESLint Stylistic, standardjs) são mencionados como alternativas ou complementos.
Filosofia da formatação
- Alguns veem a autoformatação como essencial e libertadora: o código é escrito em uma espécie de “taquigrafia” e é limpo ao salvar.
- Outros acham o Prettier medíocre, superestimado ou opinativo demais, e argumentam que a formatação é supervalorizada em relação à lógica.
- Há tensão entre ferramentas rígidas e não configuráveis (Black, padrões do Prettier) e equipes que querem mais controle sobre estilo e diffs.
- Alguns se preocupam que a forte dependência de formatadores prejudique o senso de estética de código de desenvolvedores juniores; outros consideram isso uma habilidade de baixo valor em comparação com competências de nível mais alto.