Prettier vs ESLint: a divisão de responsabilidades que ninguém explica direito

1. O mito do “ou um ou outro”: por que essa confusão persiste?

1.1. Ferramentas que parecem concorrentes, mas nasceram para ser complementares

A confusão começa no nome. Prettier e ESLint soam como dois concorrentes disputando o mesmo espaço — afinal, ambos lidam com código JavaScript. Mas a verdade é que eles atuam em camadas diferentes, como um médico e um nutricionista: um trata doenças, o outro previne problemas com hábitos saudáveis. Prettier nasceu em 2017 para acabar com debates intermináveis sobre estilo de código; ESLint veio bem antes, em 2013, para caçar bugs e impor boas práticas. Eles não foram feitos para brigar.

1.2. A sobreposição histórica: regras de estilo que o ESLint também cobria

O problema começou quando o ESLint, ao longo dos anos, acumulou regras de formatação. Coisas como indent, quotes, semi e comma-dangle eram perfeitamente funcionais no ESLint. Mas isso criou uma zona cinzenta: será que o ESLint deveria formatar o código ou apenas analisá-lo? A resposta é não, mas a tentação de usar o ESLint como formatador era grande — especialmente porque ele já estava instalado em quase todo projeto.

1.3. O erro comum de desativar o Prettier achando que ESLint resolve tudo

Já vi times inteiros desativarem o Prettier porque "o ESLint já cuida da formatação". Resultado: regras de estilo sendo mantidas manualmente, conflitos em PRs por causa de espaçamento inconsistente e uma lentidão absurda no lint. O ESLint simplesmente não foi projetado para reformatar código automaticamente. Ele aponta erros, mas não conserta tudo. Prettier, por outro lado, reescreve o arquivo inteiro com um padrão consistente.

2. A verdadeira divisão: formatação vs. linting de código

2.1. Prettier é um formatador opinativo (espaços, quebras, vírgulas)

Prettier é um formatador opinativo. Ele decide por você onde colocar quebras de linha, se usa aspas simples ou duplas, e como indentar. Você não negocia — você aceita. O benefício? Código uniforme em todo o projeto, sem discussão.

2.2. ESLint é um linter para lógica, boas práticas e erros potenciais

ESLint é um linter. Ele verifica se você está usando var em vez de let, se há variáveis não utilizadas, se uma função tem muitos parâmetros, se há vazamento de memória potencial. Ele não se importa se a indentação tem 2 ou 4 espaços — isso é problema do Prettier.

2.3. Exemplo concreto: o que cada ferramenta enxerga no mesmo trecho de código

Veja este código:

function soma(a,b){
return a+b
}

O que o Prettier enxerga: espaçamento inconsistente, falta de espaços entre parâmetros, quebra de linha ausente. Ele corrige para:

function soma(a, b) {
  return a + b;
}

O que o ESLint enxerga: falta de ponto e vírgula (se configurado), uso de function em vez de arrow function (se for a regra), ausência de tipagem (se estiver usando TypeScript). Ele não corrige a formatação, apenas avisa.

3. Onde o ESLint ainda tenta formatar (e por que isso é problemático)

3.1. Regras de estilo embutidas no ESLint que conflitam com o Prettier

Regras como max-len, comma-dangle, object-curly-spacing e quote-props são clássicas fontes de conflito. Se o ESLint exige 80 caracteres por linha e o Prettier quebra em 80, mas de forma diferente, você terá um loop infinito de correções.

3.2. O custo de manter regras de formatação manualmente no ESLint

Manter regras de formatação no ESLint é um custo oculto. Você precisa definir cada detalhe, revisar quando alguém reclama, e garantir que todos os membros do time concordam. É um desperdício de energia que poderia ser usado para resolver bugs reais.

3.3. A solução oficial: `eslint-config-prettier` para desligar conflitos

A solução é simples: instale eslint-config-prettier. Esse pacote desativa todas as regras do ESLint que entram em conflito com o Prettier. Depois disso, o ESLint só lida com lógica, e o Prettier só lida com estilo.

4. Configuração integrada sem dor de cabeça

4.1. Ordem de execução: Prettier primeiro, ESLint depois (ou em paralelo)

A ordem ideal é: primeiro formate com Prettier, depois analise com ESLint. Isso evita falsos positivos no ESLint causados por má formatação. Ou execute em paralelo, se seu editor der suporte.

4.2. Como configurar hooks de pré-commit com Husky + lint-staged

Use Husky + lint-staged para automatizar:

// package.json
{
  "husky": {
    "hooks": {
      "pre-commit": "lint-staged"
    }
  },
  "lint-staged": {
    "*.{js,jsx,ts,tsx}": [
      "prettier --write",
      "eslint --fix",
      "git add"
    ]
  }
}

Isso garante que todo commit passe por formatação e linting.

4.3. Exemplo de `package.json` com scripts combinados (formata + lint)

{
  "scripts": {
    "format": "prettier --write .",
    "lint": "eslint . --fix",
    "check": "npm run format && npm run lint"
  }
}

5. Casos de fronteira: quando a divisão fica borrada

5.1. Regras que parecem de formatação mas são de linting (ex: `no-mixed-spaces-and-tabs`)

A regra no-mixed-spaces-and-tabs parece de formatação, mas na verdade é de linting: ela previne um erro de interpretação do código. O Prettier não precisa se preocupar com isso porque ele já normaliza tudo.

5.2. Plugins que misturam responsabilidades (ex: `eslint-plugin-prettier`)

O eslint-plugin-prettier executa o Prettier dentro do ESLint. Isso é útil para quem quer uma única ferramenta, mas tem desvantagens: o ESLint fica mais lento e você perde a separação clara de responsabilidades.

5.3. Quando vale a pena usar o plugin vs. manter ferramentas separadas

Use o plugin se você quer simplicidade extrema (um comando só) e não se importa com performance. Mantenha separado se você quer velocidade, clareza e flexibilidade para atualizar cada ferramenta independentemente.

6. Como explicar a diferença para a equipe (sem virar palestra)

6.1. A analogia prática: Prettier é o revisor de ortografia; ESLint é o revisor de gramática

Prettier é como um revisor de ortografia: ele corrige erros de digitação e espaçamento. ESLint é como um revisor de gramática: ele aponta erros de concordância, uso inadequado de palavras e estruturas confusas. Um não substitui o outro.

6.2. Checklist rápido para decidir se uma regra vai para o ESLint ou Prettier

Pergunte: "Essa regra afeta a legibilidade visual ou a lógica do código?" Se for visual, vai para o Prettier. Se for lógica, vai para o ESLint. Exemplos:
- "Usar aspas simples ou duplas?" → Prettier
- "Usar == em vez de ===?" → ESLint
- "Quantos espaços de indentação?" → Prettier
- "Variável não utilizada?" → ESLint

6.3. Estratégia de adoção gradual: comece só com Prettier, depois adicione ESLint

Se sua equipe é nova nisso, comece só com Prettier. Ele é mais fácil de configurar e já traz benefícios imediatos. Depois de algumas semanas, adicione ESLint com regras básicas. Aos poucos, aumente a severidade.

7. O futuro: ferramentas que unificam (e se devemos nos preocupar)

7.1. Biome, Rome e o movimento “tudo-em-um”

Ferramentas como Biome e Rome (agora descontinuado) prometem unificar formatação e linting em um único binário. Elas eliminam a confusão de configuração e são mais rápidas por serem escritas em Rust.

7.2. O que essas novas ferramentas resolvem (e o que ainda perdem)

Elas resolvem a sobreposição e a lentidão. Mas perdem em maturidade: o ecossistema de plugins do ESLint é imenso, enquanto o Biome ainda está construindo o dele. Para projetos simples, vale a pena. Para projetos complexos, Prettier + ESLint ainda é mais seguro.

7.3. Prettier + ESLint ainda é o padrão ouro para 2024/2025?

Sim. A combinação é madura, documentada e suportada por todos os editores. Biome é promissor, mas ainda não tem a adoção massiva necessária para substituir o padrão atual. Para 2024/2025, continue com Prettier + ESLint — mas fique de olho no Biome.

Referências

Prettier Documentation — Documentação oficial do Prettier, com guias de instalação, configuração e integração com outras ferramentas.
ESLint Documentation - Rules — Lista completa de regras do ESLint, incluindo as de estilo que podem conflitar com o Prettier.
eslint-config-prettier — Repositório oficial do pacote que desativa regras conflitantes entre ESLint e Prettier.
Husky Documentation — Guia oficial do Husky para configuração de hooks Git, incluindo pré-commit com lint-staged.
lint-staged Documentation — Documentação do lint-staged, ferramenta que executa linters apenas em arquivos staged.
Biome Documentation — Documentação oficial do Biome, a ferramenta tudo-em-um que unifica formatação e linting.
Rome Tools (Archived) — Repositório arquivado do Rome, precursor do movimento de ferramentas unificadas para JavaScript/TypeScript.