Se você configurou um projeto JavaScript nos últimos anos, há uma grande chance de estar executando o Prettier por meio do eslint-plugin-prettier. Essa foi a abordagem padrão por um tempo, oferecendo uma única ferramenta e um comando unificado para resolver problemas no editor. Parecia simples, não é?
Contudo, a própria equipe do Prettier recomenda contra essa prática. Uma vez que você entender os motivos, provavelmente desejará mudar sua configuração também, como acompanhamos aqui no Brasil Vibe Coding.
Prettier É Mais Abrangente que o JavaScript
O ESLint é uma ferramenta específica para JavaScript e TypeScript. Seu mundo é limitado a essas linguagens. Quando você executa o Prettier como um plugin do ESLint, ele fica confinado a esse universo, sendo invocado apenas em arquivos que o ESLint processa.
Mas o Prettier, de forma nativa, suporta um conjunto muito mais amplo de linguagens e tipos de arquivos. Ele pode formatar CSS, Less, SCSS, HTML, JSON, YAML, Markdown (incluindo MDX), GraphQL, além de templates Vue e Angular, e Handlebars.
Pense naquele package.json com indentação inconsistente ou no arquivo .yaml de configuração onde alguém misturou tabs e espaços. E o arquivo CSS com convenções de formatação totalmente diferentes? O ESLint nunca os toca. Se o Prettier rodar apenas como plugin, esses arquivos continuarão desorganizados.
Ao executar o Prettier de forma autônoma — via CLI, integração com o editor ou um hook de pré-commit — um simples prettier --check . ou prettier --write . capturará inconsistências de formatação em todos esses tipos de arquivo no seu projeto, não apenas aqueles que o ESLint conhece. Isso é especialmente relevante em projetos do mundo real, que contêm muitos arquivos que não são JavaScript.
Maior Velocidade na Execução
Essa vantagem não é apenas uma percepção, mas é documentada pela equipe do Prettier em seu guia oficial de integração. Eles afirmam claramente que plugins do Prettier rodando dentro de linters são mais lentos do que executar o Prettier diretamente.
[Plugins do Prettier rodando dentro de linters] são mais lentos do que rodar o Prettier diretamente.
Para ser claro, ambas as abordagens (plugin ou autônoma) analisam seus arquivos JS/TS duas vezes. A diferença de desempenho vem do overhead de integração. Quando o Prettier roda como plugin, há uma camada intermediária que faz um trabalho extra para cada arquivo.
Essa camada executa o Prettier, compara a saída formatada com o original e converte cada diferença em um objeto de diagnóstico do ESLint, completo com números de linha e colunas. Em seguida, o ESLint processa todos esses diagnósticos por meio de seu pipeline de relatório e correção automática. É muita engenharia apenas para ajustar um ponto e vírgula.
O Prettier autônomo ignora tudo isso. Ele analisa, formata e escreve. Não há comparação, geração de diagnósticos ou idas e vindas pelo sistema de correção de um linter. Em uma grande base de código ou em CI/CD, esse overhead se acumula e impacta a velocidade.
Adeus, Sublinhados Vermelhos Desnecessários
Há um argumento mais sutil de experiência do usuário (UX) que a documentação do Prettier também aponta. Quando o Prettier roda como uma regra de linter, cada problema de formatação aparece como um erro de lint.
Seu editor se enche de sublinhados vermelhos e amarelos para coisas como vírgulas finais e espaçamento de chaves — itens que o Prettier corrigiria automaticamente ao salvar. O objetivo do Prettier é justamente parar de pensar em formatação. Você escreve o código como quiser, salva, e ele se encaixa no padrão.
Tratar desvios de formatação como erros de lint anula esse propósito. Isso adiciona ruído cognitivo em vez de removê-lo. Com o Prettier autônomo, a formatação acontece silenciosamente via a função de formatar ao salvar do seu editor ou um hook de pré-commit. Você só é alertado pelo Prettier quando executa explicitamente o --check no CI, que é apenas um portão de aprovação/rejeição, não uma parede de avisos no seu editor.
A Configuração Recomendada Pelos Especialistas
A documentação do Prettier estabelece uma clara separação de responsabilidades para suas ferramentas. O Prettier deve lidar exclusivamente com a formatação: indentação, comprimento da linha, pontos e vírgulas, aspas e vírgulas finais — tudo aquilo que não afeta como seu código funciona.
O ESLint, por sua vez, é o responsável pela qualidade do código. Ele deve cuidar de variáveis não utilizadas, código inatingível, globais implícitas e potenciais bugs. Essa divisão clara garante que cada ferramenta faça o que faz de melhor, otimizando seu fluxo de trabalho e a qualidade geral do projeto.
Reavaliar sua configuração e adotar a abordagem autônoma para o Prettier pode trazer benefícios significativos para a performance e a consistência do seu código. Fique ligado aqui no Brasil Vibe Coding para mais dicas de programação e otimização!