Formatador de JavaScript

O Prettier não é meramente a inspiração para a saída de formatação desta ferramenta — é o próprio pacote Prettier, baixado e rodando no seu navegador em vez de através do Node em um servidor, então o resultado é idêntico byte a byte ao que rodar `npx prettier` localmente produziria com a mesma configuração. Essa distinção importa porque formatar JavaScript é genuinamente difícil de aproximar: fazer isso corretamente exige analisar completamente a linguagem, não comparar com padrões, e um formatador que apenas aproxima o comportamento do Prettier vai divergir da configuração real do Prettier de um projeto exatamente nos casos extremos onde importa — dentro de um decorador, um tipo genérico complexo, ou uma expressão JSX incomum.

JavaScript contém várias construções que fazem uma abordagem simples de contar chaves e pontos e vírgulas falhar diretamente. Literais de template podem conter texto arbitrário entre crases, incluindo caracteres que parecem exatamente código — `` `function() { return "not real code"; }` `` é um único valor de string, não três declarações, e um formatador que não rastreia os limites de literais de template vai interpretar isso erroneamente. Literais de expressão regular são piores: `/{}/` contém caracteres que parecem chaves mas fazem parte do próprio padrão da expressão regular, não sintaxe estrutural. A inserção automática de ponto e vírgula adiciona uma terceira camada de dificuldade, já que JavaScript permite omitir pontos e vírgulas em muitos contextos e infere onde uma declaração termina segundo regras que um formatador ingênuo baseado em linhas não tem como replicar corretamente. Analisar realmente a linguagem em uma árvore de sintaxe adequada, como o Prettier faz, é o que evita os três modos de falha — um formatador de atalho que erra mesmo em um deles em código de produção é um risco, não uma conveniência.

O Prettier formata código — padroniza espaços em branco, quebras de linha, estilo de aspas e escolhas apresentacionais similares — e explicitamente não verifica se o código está correto, com tipos seguros, ou livre de erros. Um arquivo com um erro de tipo, uma referência a variável indefinida, ou um erro lógico é formatado sem reclamar desde que seja sintaticamente válido, porque formatar e verificar tipos são preocupações separadas tratadas por ferramentas separadas. O próprio compilador do TypeScript, ou um linter como o ESLint, é onde a correção é verificada; o trabalho desta ferramenta termina em tornar o código de estilo consistente e legível.

Tabulações versus espaços, aspas simples versus duplas, ponto e vírgula ou não — nenhuma dessas escolhas afeta significativamente como o código roda, e desacordos sobre elas costumavam consumir tempo real em discussões de revisão de código que não tinham nada a ver com correção. A verdadeira proposta de valor do Prettier é remover completamente esse debate da mesa: um pequeno conjunto opinativo de regras de formatação aplicado automática e identicamente em todo lugar significa que o debate é resolvido uma vez, na configuração, em vez de repetidamente em cada pull request daí em diante.

Cada opção exposta aqui — largura de indentação, ponto e vírgula, estilo de aspas — reflete uma configuração real do Prettier, então colar código de um projeto com um `.prettierrc` conhecido e igualar essas mesmas configurações aqui reproduz exatamente o que a própria ferramenta daquele projeto produziria, sem precisar instalar nada localmente apenas para verificar como um trecho seria formatado.