Prettier

O que é o Prettier?

O Prettier é um formatador de código opinativo. Ele analisa o seu código transformando-o em uma árvore de sintaxe e o reimprime com um layout determinístico, ignorando os espaços em branco que você escreveu. O resultado depende apenas da estrutura do código e de um pequeno conjunto de opções, portanto, a mesma entrada sempre produzirá a mesma saída.

Esse determinismo é o ponto principal. As discussões sobre estilo desaparecem porque quem decide é o formatador, não a equipe. Os diffs diminuem para mostrar apenas as mudanças reais em vez de alterações irrelevantes de espaçamento, e os revisores gastam seu tempo com a lógica e o design. O Prettier é uma das poucas ferramentas que reduz a fricção em uma base de código de forma mensurável.

Configuração

O Prettier funciona sem a necessidade de configuração, mas você pode definir algumas opções em .prettierrc.

{
  "semi": true,
  "singleQuote": false,
  "trailingComma": "all",
  "printWidth": 100,
  "tabWidth": 2,
  "arrowParens": "always"
}

Essas são as opções que a maioria das equipes costuma ajustar. Além delas, o Prettier toma as decisões. Quanto menos opções você definir, mais consistente será o resultado entre os projetos e menor será a manutenção.

Executando o Prettier

Formate arquivos no local ou verifique as alterações sem gravá-las.

npx prettier --write .
npx prettier --check .
npx prettier --write src/app.tsx

--write reformata e salva; --check reporta os arquivos que seriam alterados e retorna um código de saída diferente de zero, que é exatamente o que o CI precisa. Adicione um script para que os comandos sejam consistentes.

{
  "scripts": {
    "format": "prettier --write .",
    "format:check": "prettier --check ."
  }
}

Ignorando arquivos

.prettierignore lista os caminhos a serem ignorados, utilizando a mesma sintaxe do .gitignore.

dist
coverage
pnpm-lock.yaml
*.generated.ts

Ignorar a saída do build e arquivos gerados é importante: formatá-los gera ruído que será sobrescrito no próximo build e pode até quebrar a geração de código que espera um layout específico.

Integração com o editor

Instale a extensão do Prettier no seu editor e ative a opção de formatar ao salvar (format on save). É aqui que o Prettier traz o maior benefício: você nunca precisa se preocupar com a formatação, e cada salvamento deixa o arquivo limpo. Isso também significa que você pode usar --check no CI com confiança, pois a formatação acontece continuamente, em vez de exigir uma grande limpeza ao final.

Trabalhando com ESLint

O Prettier e o ESLint possuem sobreposições em regras de estilo e, se deixados sozinhos, entrarão em conflito. A solução padrão é deixar o Prettier cuidar da formatação e desativar as regras conflitantes do ESLint.

// eslint.config.js
import js from "@eslint/js";
import prettier from "eslint-config-prettier";

export default [js.configs.recommended, prettier];

O eslint-config-prettier desativa todas as regras do ESLint que conflitam com o Prettier, permitindo que o ESLint foque na qualidade do código e o Prettier no layout. Se você deseja que problemas de formatação sejam exibidos como erros de lint, o eslint-plugin-prettier executa o Prettier como uma regra, embora muitas equipes prefiram manter os dois separados.

Pre-commit hooks

Formatar o código antes de um commit mantém o CI verde e o histórico limpo.

{
  "lint-staged": {
    "*.{js,jsx,ts,tsx,css,md}": "prettier --write"
  }
}

Combinado com um hook runner como o husky, isso formata apenas os arquivos em stage, garantindo que os commits continuem rápidos. É uma configuração simples que evita toda uma categoria de comentários de “código não formatado” durante o code review.

Onde o Prettier se encaixa

O Prettier serve apenas para formatação. Ele não encontra bugs, não impõe tipos nem verifica imports — essas tarefas pertencem ao ESLint e ao verificador de tipos. Um toolchain saudável executa os três: Prettier para o layout, ESLint para a qualidade e TypeScript para os tipos. Cada um tem uma função específica e nenhum deles conflita com os outros.

Melhores práticas

• Aceite os padrões, a menos que sua equipe tenha um motivo forte para alterar algum.
• Faça o commit de um .prettierrc para que todos os editores e execuções de CI estejam alinhados.
• Adicione .prettierignore para a saída do build e arquivos gerados.
• Configure a formatação ao salvar no editor.
• Execute --check no CI e --write em um pre-commit hook.
• Desative regras conflitantes do ESLint com eslint-config-prettier.
• Mantenha a lista de opções curta.

Erros comuns

• Deixar que o ESLint e o Prettier formatem o código simultaneamente, gerando conflitos.
• Formatar arquivos gerados automaticamente, criando diffs poluídos.
• Pular a verificação de CI, permitindo que código não formatado seja mergeado.
• Alterar opções por projeto sem motivo, perdendo a consistência entre diferentes projetos.
• Executar o Prettier no repositório inteiro em um pre-commit hook, tornando os commits lentos.
• Usar o Prettier para impor regras semânticas que deveriam pertencer ao ESLint.

Próximos passos

O Prettier elimina toda uma categoria de trabalho repetitivo. Combine-o com o ESLint para qualidade, TypeScript para segurança de tipos, e integre ambos ao seu projeto Vite e ao seu CI. Depois, configure a formatação ao salvar e nunca mais se preocupe com espaçamentos.